plplot-devel — Technical discussion about PLplot development

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

[Geoffrey F. <fu...@li...>]

Alan W. Irwin writes:
 > > > Also we need some input from Geoffrey (now that Maurice is gone on
 > > > vacation) about the status of tcl/tk wish and tclsh plplot support on
 > > > solaris (and the Linux distributions he has access to).
 > >
 > > If your LIBRARY_VERSION hack works for Linux and Soalris, at least, let us
 > > keep it for now.  I may find a solution in the future to adjust pkgIndex.tcl
 > > using the information available in libplplot.la.  I think that it is a bad
 > > idea delaying the release for that.  Of course, we should add a note in the
 > > announcement about this problem.
 > >
 > > Someone already said "release often, release early", and we should adopt
 > > this motto.
 > 
 > I absolutely agree.  If we know we are going to release often (say once per
 > quarter), then I think everybody will not worry so much about release
 > deadlines and just relax and do their best work.
 > [...]
 > The only really big uncertainty at the moment is solaris. Apparently some
 > time ago the big December AT change was tested (at least partially) by
 > Maurice for solaris, but that doesn't say much about the current status.
 > 
 > What is the solaris testing story, Geoffrey?  Please make as good an
 > estimate as possible about whether you or Maurice (when he is back from
 > vacation) are likely in the near future to spend the hour or so required for
 > a straightforward functionality test (plplot-test.sh and all the interactive
 > tests mentioned in README.tcldemos and README.tkdemos). Even if a part of it
 > doesn't work, we don't have to get involved in fixing it unless it is
 > something really simple.  All we really have to do is make sure the solaris
 > limitations (if any) are documented for the release.

Maurice won't be back in the loop till Monday.  I'm off starting Friday am
for a long weekend too.  Tomorrow I have just about a half day.  I'll see if
I can fit in a Solaris eval tomorrow afternoon, but honestly, it's a long
shot.  There is a real possibility that you won't get anything meaningful out
of either of us until next week.

-- 
Geoffrey Furnish         Lightspeed Semiconductor Corp
voice: 512-402-9016      11612 Bee Cave Road, Suite 130
fax:   512-402-9643          Austin, Texas   78738

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

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

On Wednesday 16 April 2003 23:21, Alan W. Irwin wrote:
|  On Wed, 16 Apr 2003, Rafael Laboissiere wrote:
|  > I have no time to look at p16.m right now and I doubt that I will do
|  > during the next week.  Doing this means code analysis and it will take
|  > much more time than the mechanical work of tarball generation or even
|  > the fixing of obvious bugs.
|  >
|  > I would vote for the patch for now.
|
|  I will go along with whatever you and Joao decide.  You have now both
|  confirmed the bug, and last I heard it sounded like he was on a promising
|  trail (finding a similar problem for another example), but if that doesn't
|  pan out, the patch is an ugly but acceptable solution for a temporary
|  release-only workaround.

After burning the CD and installing the XP package(*), I have changed octave 
plsetop(). With this change the problem seems to be solved, but please check 
it.

| Also, if something doesn't get done in time for release all
| we have to do is be clear in the announcement or associated documentation
| about any limitations there may be.

Agree.

Joao

(*) The XP package is fantastic! It emulates a real OS in almost all details!

Re: [Plplot-devel] Desperado! [was: Two issues [ xwin problem, cont.]]

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

On Wednesday 16 April 2003 22:07, Sebastian Kuzminsky wrote:
|  =?iso-8859-1?q?Jo=E3o=20Cardoso?= <jc...@fe...> wrote:
|

In include/pldebug.h, one can find the following sentence:

      /* For the truly desperate debugging task */

This is the case. It's going to depend much on you. Add the following to 
include/pldebug.h:

#define DEBUG 
#define DEBUG_ENTER

recompile, reinstall, and report again. This is going to produce lots of 
messages, gzip it and send to me. It's also a good oportunity to use the last 
sources plplot-5.2.1.rc1.tar.gz (not that they had changed meanwhile, but).

Thanks for your perseverance,

Joao

PS-what's the version of your gcc?

|  --
|  Sebastian

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

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

On Wed, 16 Apr 2003, Rafael Laboissiere wrote:

> I have no time to look at p16.m right now and I doubt that I will do during
> the next week.  Doing this means code analysis and it will take much more
> time than the mechanical work of tarball generation or even the fixing of
> obvious bugs.
>
> I would vote for the patch for now.

I will go along with whatever you and Joao decide.  You have now both
confirmed the bug, and last I heard it sounded like he was on a promising
trail (finding a similar problem for another example), but if that doesn't
pan out, the patch is an ugly but acceptable solution for a temporary
release-only workaround.

> > Regardless of Rafael's decision for this p16 problem, I also would like some
> > resolution to the no-familying bug he found on his home machine yesterday.
>
> Let us forget that.  I erased many things that I did yesterday and my
> machine at home is running Debian unstable, so its system is changing on a
> day-to-day basis.

That's fine if everything works again there, but not so good if familying
continues not to work.  If the problem persists you should be quickly able
to see whether it is a bash bug or script bug that is preventing the exported
options variable to be passed to test_octave.sh.  If that variable is getting
through okay, then there may be a problem with plsetopt for Debian unstable,
but that is also easy to test and either note the limitation to be documented
for the release or fix it.

>
> > Also we need some input from Geoffrey (now that Maurice is gone on
> > vacation) about the status of tcl/tk wish and tclsh plplot support on
> > solaris (and the Linux distributions he has access to).
>
> If your LIBRARY_VERSION hack works for Linux and Soalris, at least, let us
> keep it for now.  I may find a solution in the future to adjust pkgIndex.tcl
> using the information available in libplplot.la.  I think that it is a bad
> idea delaying the release for that.  Of course, we should add a note in the
> announcement about this problem.
>
> Someone already said "release often, release early", and we should adopt
> this motto.

I absolutely agree.  If we know we are going to release often (say once per
quarter), then I think everybody will not worry so much about release
deadlines and just relax and do their best work.

>
> [out of order] As regards the plans for the release, it seems that we are already behind
> schedule.  What about delaying the announcement of one week, but releasing
> RC2 this coming weekend?

I think it is better for all of us not to delay the release by more than a
day or two at most, and I still think there is an excellent chance to get it
out this Saturday on time.  Since this deadline has been known long in
advance, I planned my life accordingly and next weekend after this is not
particularly good for me, and I imagine it is the same story for most of the
rest of us. Also, if something doesn't get done in time for release all we
have to do is be clear in the announcement or associated documentation about
any limitations there may be.

The octave decisions are under Joao's and your control.  I think for both
sets of problems there you are in a position for a fix, a workaround or
simply noting the limitation.  So I don't think those issues should delay
the release from this weekend.

The only really big uncertainty at the moment is solaris. Apparently some
time ago the big December AT change was tested (at least partially) by
Maurice for solaris, but that doesn't say much about the current status.

What is the solaris testing story, Geoffrey?  Please make as good an
estimate as possible about whether you or Maurice (when he is back from
vacation) are likely in the near future to spend the hour or so required for
a straightforward functionality test (plplot-test.sh and all the interactive
tests mentioned in README.tcldemos and README.tkdemos). Even if a part of it
doesn't work, we don't have to get involved in fixing it unless it is
something really simple.  All we really have to do is make sure the solaris
limitations (if any) are documented for the 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] Two issues [ xwin problem, cont.]

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

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

> It's in src/plsymc.c, in the function plfntld().  I'm using the debian
> packages from the sourceforge website, the version is "5.2.0.cvs.20030403".
> The printf is not indented like the rest of the code, looks like somebody
> slipped in a debug print statement.

That is probably my fault, sorry.  Anyway, there are newer Debian package in
http://plplot.sourceforge.net/resources/debian/

-- 
Rafael

Re: [Plplot-devel] Two issues [ xwin problem, cont.]

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

=?iso-8859-1?q?Jo=E3o=20Cardoso?= <jc...@fe...> wrote:
] Your problem does not occur only with x07c, does it? Any demo that uses 
] the xwin driver has the probem, right?


Right, none of the examples work with the xwin driver, and all work with
gnome and tk/ntk drivers.




] | i=15, r=1, pixel=16777215
] | Allocated 16 colors in cmap0.
] | CreatePixmap: creating pixmap: width = 1200, height = 900, depth = 24
] | fnt: 1
] 
] This is odd. In my system the string "fnt: " is not printed! In my 
] system,
] 
] ...
] i=15, r=1, pixel=65535
] Allocated 16 colors in cmap0.
] CreatePixmap: creating pixmap: width = 864, height = 648, depth = 16
] LookupXKeyEvent: Keysym ff0d, translation: 
] ...
] 
] There is no occurence of that string in the library, drivers or examples 
] sources! What's happening?


It's in src/plsymc.c, in the function plfntld().  I'm using
the debian packages from the sourceforge website, the version is
"5.2.0.cvs.20030403".  The printf is not indented like the rest of the
code, looks like somebody slipped in a debug print statement.




] HUH!
] Also, your pixmap is too big! The default window size is 864 x 648, and 
] the pixmap should have the same size. E.g., if I:
] 
] ./x07c -dev xwin -debug -verbose -geo 200x300
] ...
] CreatePixmap: creating pixmap: width = 200, height = 300, depth = 16
] ...
] 
] Please try using the -geo option and report the size of the pixmap 
] created.


Still no joy:

0 seb@dub /home/seb/tmp/plplot>  ./x07c -verbose -debug -dev xwin -geo 200x300
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
using default visual
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 = 200, height = 300, depth = 24
fnt: 1


Again the window is created and immediately destroyed.




--
Sebastian

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

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

On Wed, 16 Apr 2003, [iso-8859-1] Jo=E3o Cardoso wrote:

> | With regard to (4) I just tried Rafael's patch, and I confirm it is
> | really slow with an interactive GUI popping on and off the screen for
> | every p example (as opposed to just the first one before).
>
> Do you remember if this happened before? I find it odd. I recently made
> octave plsetop() to open an window if none is already opened, but for
> this test it is ugly.

I don't recall the dead GUI for anything before RC1, but it has been a whil=
e
since I tested.

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] Poor RC1 test results on Debian woody

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

On Wednesday 16 April 2003 18:35, Alan W. Irwin wrote:
| On Wed, 16 Apr 2003, [iso-8859-1] Jo=E3o Cardoso wrote:
| > On Wednesday 16 April 2003 16:13, Alan W. Irwin wrote:
| > | On Wed, 16 Apr 2003, Rafael Laboissiere wrote:
| > | > * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]:
=2E..
| > 2-make the surface plots z axis aware ( I had no feedback on this)
|
| There are no hard and fast rules about the appropriate time for
| making this fix. You are closest to the extent of the changes you
| have to make, and it is your judgement call balancing the benefits of
| a fix with the chances of introducing another bug.  Presumably, you
| will have thoroughly tested your fix under Linux and OSF1.  Under
| those conditions I would be all for making the fix unless it
| introduces complications such as new API, new system libraries, new
| headers, etc. which might introduce cross-platform issues on
| platforms other than Linux and OSF1.

Just a couple of code line changes. Done.
=2E..
| > 4-look at p16.
|
| With regard to (4) I just tried Rafael's patch, and I confirm it is
| really slow with an interactive GUI popping on and off the screen for
| every p example (as opposed to just the first one before).

Do you remember if this happened before? I find it odd. I recently made=20
octave plsetop() to open an window if none is already opened, but for=20
this test it is ugly.

|  So it
| gives a bad impression, but at least it doesn't crash, and it appears
| there are no overwrites of previous files by p16 (presumably because
| of Rafael's reinitialization before p16 is run).

At the office computer I can also reproduce the bug. But... changing=20
test_octave.sh such that the only tests are p15, p16 and adding p21,=20
gives the following:

Opened p15.png.01
Opened p15.png.02
Opened p16.png.01
Opened p21.png.01

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

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

etc. Thus the problem is not in p16!!! While the XP CD is burning I will=20
take a look.

Joao

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

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

* Alan W. Irwin <ir...@be...> [2003-04-16 10:35]:

> Clearly, Joao has run out of time (as have I because there is a full
> announcement I have to write for the release as well as my other work) so
> the final decision is really up to Rafael.  I do ask Rafael to have a quick
> look at p16 to see if there is any obvious familying initialization
> problem. I don't know octave well enough to trace this back to the
> equivalent PLplot function calls, but at a low level, pladv has to be
> invoked in exactly the right order as in my recent x21c.c fix for familying
> to work properly. Perhaps comparison with the initialization in p7 and p15
> (both of which have no familying problems) will help sort this out. If
> Rafael cannot find anything or has run out of time to deal with this bug, I
> would be willing to go along with the patch on a temporary basis to work
> around it just for this release.

I have no time to look at p16.m right now and I doubt that I will do during
the next week.  Doing this means code analysis and it will take much more
time than the mechanical work of tarball generation or even the fixing of
obvious bugs.

I would vote for the patch for now.

As regards the plans for the release, it seems that we are already behind
schedule.  What about delaying the announcement of one week, but releasing
RC2 this coming weekend?

> Regardless of Rafael's decision for this p16 problem, I also would like some
> resolution to the no-familying bug he found on his home machine yesterday.

Let us forget that.  I erased many things that I did yesterday and my
machine at home is running Debian unstable, so its system is changing on a
day-to-day basis.

> Also we need some input from Geoffrey (now that Maurice is gone on
> vacation) about the status of tcl/tk wish and tclsh plplot support on
> solaris (and the Linux distributions he has access to).

If your LIBRARY_VERSION hack works for Linux and Soalris, at least, let us
keep it for now.  I may find a solution in the future to adjust pkgIndex.tcl
using the information available in libplplot.la.  I think that it is a bad
idea delaying the release for that.  Of course, we should add a note in the
announcement about this problem.

Someone already said "release often, release early", and we should adopt
this motto.

-- 
Rafael

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

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

On Wed, 16 Apr 2003, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Wednesday 16 April 2003 16:13, Alan W. Irwin wrote:
> | On Wed, 16 Apr 2003, Rafael Laboissiere wrote:
> | > * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]:
>
> | So we may have more than one problem here, but it still looks to me
> | that p16 is not being set up properly.  What do you think, Joao?
>
> It might be a bug.
>
> My priorities at the moment are:
> 1-add "-drvopt defvis" to xwin

Just saw that in cvs.  Thanks!  I also hope you have time to follow up with
Sebastian Kuzminsky's X problem.  Sounded like you were close to finding th=
e
X server conditions where xwin did not work (but tk and ntk do work), and h=
e
seemed very cooperative about running tests to find out the source of this
strange problem.

> 2-make the surface plots z axis aware ( I had no feedback on this)

There are no hard and fast rules about the appropriate time for making this
fix. You are closest to the extent of the changes you have to make, and it
is your judgement call balancing the benefits of a fix with the chances of
introducing another bug.  Presumably, you will have thoroughly tested your
fix under Linux and OSF1.  Under those conditions I would be all for making
the fix unless it introduces complications such as new API, new system
libraries, new headers, etc. which might introduce cross-platform issues on
platforms other than Linux and OSF1.

> 3-install the XP package on my computer (XP is from M$ :)

XP sounds like a black hole that will suck you in forever....;-)

> 4-look at p16.

With regard to (4) I just tried Rafael's patch, and I confirm it is really
slow with an interactive GUI popping on and off the screen for every p
example (as opposed to just the first one before).  So it gives a bad
impression, but at least it doesn't crash, and it appears there are no
overwrites of previous files by p16 (presumably because of Rafael's
reinitialization before p16 is run).

Clearly, Joao has run out of time (as have I because there is a full
announcement I have to write for the release as well as my other work) so
the final decision is really up to Rafael.  I do ask Rafael to have a quick
look at p16 to see if there is any obvious familying initialization problem=
=2E
I don't know octave well enough to trace this back to the equivalent PLplot
function calls, but at a low level, pladv has to be invoked in exactly the
right order as in my recent x21c.c fix for familying to work properly.
Perhaps comparison with the initialization in p7 and p15 (both of which hav=
e
no familying problems) will help sort this out. If Rafael cannot find
anything or has run out of time to deal with this bug, I would be willing t=
o
go along with the patch on a temporary basis to work around it just for thi=
s
release.

Regardless of Rafael's decision for this p16 problem, I also would like som=
e
resolution to the no-familying bug he found on his home machine yesterday.
Also we need some input from Geoffrey (now that Maurice is gone on
vacation) about the status of tcl/tk wish and tclsh plplot support on
solaris (and the Linux distributions he has access to).

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] Poor RC1 test results on Debian woody

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

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

| So we may have more than one problem here, but it still looks to me
| that p16 is not being set up properly.  What do you think, Joao?

It might be a bug.

My priorities at the moment are:
1-add "-drvopt defvis" to xwin
2-make the surface plots z axis aware ( I had no feedback on this)
3-install the XP package on my computer (XP is from M$ :)
4-look at p16.

The reason why I put 1 and 2 first is that I know exactly what to do.
 3 has to be done ASAP.
 4 *might* be a bug and to check/fix it might take more time.

Joao

|
| BTW, I don't care how test_octave.sh is modified so long as the
| result always works and it is not some gross workaround to a known
| problem that can be fixed in an easier way. I will try the patch (or
| Joao's modification of it) to test_octave.sh after Joao and you have
| had a chance to react on the simple test and Joao has had a chance to
| react to my concern that p16 is not being set up the same as the
| other p examples.
|
| 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

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

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

* João Cardoso <jc...@fe...> [2003-04-16 14:18]:

> As I would have to read the auto-things info pages to solve that, and I 
> don't have all that time... unless someone else has the expertise at 
> his fingertips :) it will remain as is.

Okay, this is post-5.2.1 work.

-- 
Rafael

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

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

On Wednesday 16 April 2003 08:51, Rafael Laboissiere wrote:
| * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]:
...

| My guess is that text_octave.sh is doing things in the wrong way, by
| calling plplot_stub only once and then looping over the p??.m files. 
| Now, each file needs a different way of being initialized and then
| the clash happens in p16.m.

Perhaps.

| In other words, the bug is in test_octave.sh!
|
| I propose the patch attached below.  The loop is done at the shell
| level and octave is called individually for each demo file.  It is
| much slower, but it works.  Joao and Alan: do you agree with the
| patch?

If it works, go ahead!

Latter I *should* see what is p16 triggering (or is it the *previous* 
demo?), and correct it.

Joao

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

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

On Wed, 16 Apr 2003, Rafael Laboissiere wrote:

> * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]:
> > The simple problem being solved here is that wish and tclsh need to know
> > the _complete_ PLplot library names so they can load them.  Maurice, I
> > wonder if 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 version of this file installed on my system has the following
> > line:
> >
> > library_names='libplplotd.so.5.3.0 libplplotd.so.5 libplplotd.so' and
> >
> > similarly for libplplottcltkd
> >
> > library_names='libplplottcltkd.so.5.3.0 libplplottcltkd.so.5 libplplottcltkd.so'
> >
> > If solaris lib*.la files have something similar, Maurice or Geoffry might be
> > 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.
>
> What you re proposing is reasonable and does not seem difficult to
> implement.  However, I am reluctant to do it, since my knowledge of Tcl/Tk
> is exactly equal to zero and am not willing to improve this situation before
> the release.

I am virtually in the same boat.  (I can stumble my way through a tcl script
by constant reference to the man pages, but that is about it.) So this is
just one suggestion for Maurice and Geoffrey as a cross-platform way out of
this.  However, if they find the current LIBRARY_VERSION kludge works on
solaris for running plplot under wish and tclsh, then that is probably good
enough for now.

>
> > Well, I certainly do _not_ get those results on Debian woody.  It appears we
> > have now found two bugs.  The result you have above is completely incorrect
> > because there is no familying.
>
> Sorry, I was doing something wrong yesterday.  I did in my computer at home
> (inaccessible right now), and I cannot tell now what the difference is.

Please follow up on this; it may well be a bug in plplot-test.sh that you have
found.  If you run that script you should *always* get familying for png:

See

case $device in

   png)
      dsuffix=png
      export dsuffix
      options="-fam -fflen 2"
      export options
      ;;

But your results were as if the -fam option never got propagated to
test_octave.sh so apparently you have found a way to clobber options which I
would like to see fixed.

> As
> a matter of fact, I can reproduce here the bug yuo found.

That's a great relief that we are finally on the same page!

>
> My guess is that text_octave.sh is doing things in the wrong way, by calling
> plplot_stub only once and then looping over the p??.m files.  Now, each file
> needs a different way of being initialized and then the clash happens in
> p16.m.
>
> In other words, the bug is in test_octave.sh!

That is certainly possible.  But before we deal with that, let's look at
simpler examples.  What is your result for the simple octave example I put
together that showed the bug yesterday?  First, do you confirm it, and
second do you and Joao feel that you should not call a p example more than
once after plsetopt and figure?  I looked at those results a bit more, and
it seems that p16 overwrites whatever file is open killing the previous p
example's plot.  But p7 and the rest I tried do not have this behaviour. It
is possible p16 has _always_ overwritten the previous plot when in familying
mode, I haven't checked in that sort of detail before.

So we may have more than one problem here, but it still looks to me that p16
is not being set up properly.  What do you think, Joao?

BTW, I don't care how test_octave.sh is modified so long as the result
always works and it is not some gross workaround to a known problem that can
be fixed in an easier way. I will try the patch (or Joao's modification of
it) to test_octave.sh after Joao and you have had a chance to react on the
simple test and Joao has had a chance to react to my concern that p16 is not
being set up the same as the other p examples.

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] Two issues

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

On Wednesday 16 April 2003 07:04, Maurice LeBrun wrote:
| Joao Cardoso writes:
|  > 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?
|
| It was my plan to recode this section of the xwin driver, such that
| it always uses the default visual, unless overridden by a -drvopt
| flag.  I think the default visual makes for a fine default, probably
| more useful than the way we do it now.  And the -drvopt support means
| that one can always "fix" it at runtime, or at least debug it easier.
|  In addition for displays that support multiple visuals it is a nice
| plus to the user to be able to select it at runtime.  Should probably
| provide a configuration option to use the legacy approach, but also
| in that case have it be overridden by use of -drvopt.
|
| Anyway, I'd planned on doing this work nearly a year ago, and am now
| much busier than I was then, so if someone else wants to take a whack
| at it please feel free.

I can try to get time to add a "-drvopt defvis" option to xwin, that 
just turns on/off the driver code section now conditionally commented.
The default will still be the same as is now, just to be on the right 
side of the fence.

Better than nothing.
Joao

Re: [Plplot-devel] Two issues [ xwin problem, cont.]

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

On Wednesday 16 April 2003 06:47, Sebastian Kuzminsky wrote:
| Joao Cardoso <jc...@fe...> wrote:
| ] 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.
|
|
| I can't get xwin to work on two of my systems.  I'm motivated to get
| it working and will give you any assistance i can in fixing it.

Sebastian, your problem symptons do not fit in the USE_DEFAULT_VISUAL 
problem I address here. But thanks!

What happens in those situations is:

  X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  1 (X_CreateWindow)
  Serial number of failed request:  10
  Current serial number in output stream:  14

...

| Here's the screen info from xdpyinfo on the two systems that dont
| work with xwin:
|
|
| Machine 1
| ATI Radeon Mobility 9000
| XFree86 4.2.1 running in VESA mode

On this machine only True Color visuals are supported, it is not a 
candidate to hunt the USE_DEFAULT_VISUAL problem.

...

| Machine 2
| nVidia GeForce 2 Go
| XFree86 4.1.0.1

Unfortunately no Pseudo Color visual is also present on this one

| And here's one of my machines that work, just because:
| i810
| XFree86 4.2.1

No Pseudo Color visual also.

The data collected from other users seems to require a pseudocolor 
*together* with a truecolor visual to trigger the problem. 

As Rafael, I'm also puzzled with your problem...

| I tried enabling USE_DEFAULT_VISUAL in xwin.c like you suggested.

I didn't suggest that, because the description you sent did not fit :)

| I added a line that said "#define USE_DEFAULT_VISUAL" to right under
| the comment that talks about it and recompiled.  Had a minor build
| problem, it's missing Build-Depends on g++.  Installed the new
| packages. Recompiled the examples, probably unnecessary since it's
| dynamically linked but hey.  Anyway, it still didnt work, same
| problem as before. "x07c -verbose -debug -dev xwin" says this (on the
| machine with the ATI):

Your problem does not occur only with x07c, does it? Any demo that uses 
the xwin driver has the probem, right?

...

| i=15, r=1, pixel=16777215
| Allocated 16 colors in cmap0.
| CreatePixmap: creating pixmap: width = 1200, height = 900, depth = 24
| fnt: 1

This is odd. In my system the string "fnt: " is not printed! In my 
system,

...
i=15, r=1, pixel=65535
Allocated 16 colors in cmap0.
CreatePixmap: creating pixmap: width = 864, height = 648, depth = 16
LookupXKeyEvent: Keysym ff0d, translation: 
...

There is no occurence of that string in the library, drivers or examples 
sources! What's happening?

HUH!
Also, your pixmap is too big! The default window size is 864 x 648, and 
the pixmap should have the same size. E.g., if I:

./x07c -dev xwin -debug -verbose -geo 200x300
...
CreatePixmap: creating pixmap: width = 200, height = 300, depth = 16
...

Please try using the -geo option and report the size of the pixmap 
created.

Joao

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

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

On Wednesday 16 April 2003 09:18, Rafael Laboissiere wrote:
| * Volker Naulin <vol...@ri...> [2003-04-16 09:51]:
| > On Wed, 16 Apr 2003, Rafael Laboissiere wrote:
| > > * Volker Naulin <vol...@ri...> [2003-04-16 09:34]:
| > > > However if you install it by "make install" plplot does not
| > > > find the library by default (again, linux mandrake 9.0)
| > >
| > > This is probably due to the fact that it installs the so file in
| > > a directory not accessible to ld.so.  Have you tried ./configure
| > > --prefix=/usr?
| >
| > Shure I'm able to fix this manually, but hej, great idea if it
| > already works with defaults.....
|
| Yes, you are right.  This is already done for all the other libraries
| searched by PLplot's configure (gd, jpeg, z, freetype, etc), but has
| not yet been implemented for qhull.  I doubt that we are doing this
| before the 5.2.1 release.  Joao?

As I would have to read the auto-things info pages to solve that, and I 
don't have all that time... unless someone else has the expertise at 
his fingertips :) it will remain as is.

Joao

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

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

* Volker Naulin <vol...@ri...> [2003-04-16 09:51]:

> On Wed, 16 Apr 2003, Rafael Laboissiere wrote:
> 
> > * Volker Naulin <vol...@ri...> [2003-04-16 09:34]:
> >
> > > However if you install it by "make install" plplot does not find the
> > > library by default (again, linux mandrake 9.0)
> >
> > This is probably due to the fact that it installs the so file in a directory
> > not accessible to ld.so.  Have you tried ./configure --prefix=/usr?
> 
> 
> Shure I'm able to fix this manually, but hej, great idea if it already
> works with defaults.....

Yes, you are right.  This is already done for all the other libraries
searched by PLplot's configure (gd, jpeg, z, freetype, etc), but has not yet
been implemented for qhull.  I doubt that we are doing this before the 5.2.1
release.  Joao?

-- 
Rafael

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

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

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

> 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.

Do not count on me.  I never wrote a single line of Tcl in my life...

> The simple problem being solved here is that wish and tclsh need to know
> the _complete_ PLplot library names so they can load them.  Maurice, I
> wonder if 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 version of this file installed on my system has the following
> line:
> 
> library_names='libplplotd.so.5.3.0 libplplotd.so.5 libplplotd.so' and
> 
> similarly for libplplottcltkd
> 
> library_names='libplplottcltkd.so.5.3.0 libplplottcltkd.so.5 libplplottcltkd.so'
> 
> If solaris lib*.la files have something similar, Maurice or Geoffry might be
> 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.

What you re proposing is reasonable and does not seem difficult to
implement.  However, I am reluctant to do it, since my knowledge of Tcl/Tk
is exactly equal to zero and am not willing to improve this situation before
the release.

> Well, I certainly do _not_ get those results on Debian woody.  It appears we
> have now found two bugs.  The result you have above is completely incorrect
> because there is no familying.

Sorry, I was doing something wrong yesterday.  I did in my computer at home
(inaccessible right now), and I cannot tell now what the difference is.  As
a matter of fact, I can reproduce here the bug yuo found.

My guess is that text_octave.sh is doing things in the wrong way, by calling
plplot_stub only once and then looping over the p??.m files.  Now, each file
needs a different way of being initialized and then the clash happens in
p16.m.

In other words, the bug is in test_octave.sh!

I propose the patch attached below.  The loop is done at the shell level and
octave is called individually for each demo file.  It is much slower, but it
works.  Joao and Alan: do you agree with the patch?

> 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.

The test_octave.sh problem is a non-bug, and can be "fixed".  The Tcl/Tk one
is a real problem.  It is just too irritating that we should delay the
release because of it, but I think we have no choice.

-- 
Rafael

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

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

On Wed, 16 Apr 2003, Rafael Laboissiere wrote:

> * Volker Naulin <vol...@ri...> [2003-04-16 09:34]:
>
> > However if you install it by "make install" plplot does not find the
> > library by default (again, linux mandrake 9.0)
>
> This is probably due to the fact that it installs the so file in a directory
> not accessible to ld.so.  Have you tried ./configure --prefix=/usr?


Shure I'm able to fix this manually, but hej, great idea if it already
works with defaults.....

Volker

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

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

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

* Volker Naulin <vol...@ri...> [2003-04-16 09:34]:

> However if you install it by "make install" plplot does not find the
> library by default (again, linux mandrake 9.0)

This is probably due to the fact that it installs the so file in a directory
not accessible to ld.so.  Have you tried ./configure --prefix=/usr?

-- 
Rafael

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

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

On Tue, 15 Apr 2003, Jo=E3o Cardoso wrote:


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

The Qhull source page is unavailable for me as well :-(.


>
> I don't think we should include it in PLplot. We could however provide
> 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.
>
>   To unpack the gzip file
>   - tar zxf qhull.tgz
>   - cd qhull
>
>   Compiling with the Debian Make:[R. Laboissiere]
>   - cd src
>   - ./Make-config.sh
>   - cd ..
>   - configure
>   - make

However if you install it by "make install" plplot does not find the
library by default (again, linux mandrake 9.0)

Cheers
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
*****************************************************************

Re: [Plplot-devel] Two issues

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

Maurice LeBrun <mj...@ga...> wrote:
] It was my plan to recode this section of the xwin driver, such that it always
] uses the default visual, unless overridden by a -drvopt flag.  I think the
] default visual makes for a fine default, probably more useful than the way we
] do it now.  And the -drvopt support means that one can always "fix" it at
] runtime, or at least debug it easier.  In addition for displays that support
] multiple visuals it is a nice plus to the user to be able to select it at
] runtime.  Should probably provide a configuration option to use the legacy
] approach, but also in that case have it be overridden by use of -drvopt.


Hi Maurice, i've trying to get xwin working on a couple of machines
i have where it's currently broken.  When i run the examples, plinit()
creates a window but it's destroyed immediately - before plinit() returns.
Other drivers like tk and gnome work fine.  The examples display to
other X servers over the net fine, just not to these two displays i have.


I tried the three drvopts defined in xwin.c, none made it work.  I guess
you were talking about adding a drvopt to select the visual?  And use
the default visual by, well, by default?


I tried Joao Cardoso's suggestion of recompiling the library with
USE_DEFAULT_VISUAL defined in xwin.c, but that also didnt make it work.




] Anyway, I'd planned on doing this work nearly a year ago, and am now much
] busier than I was then, so if someone else wants to take a whack at it please
] feel free.


I'm a reasonable C programmer but i've never done any X programming.
If you tell me what to do i'll try to implement it....




--
Sebastian

Re: [Plplot-devel] Two issues

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

Joao Cardoso writes:
 > 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?

It was my plan to recode this section of the xwin driver, such that it always
uses the default visual, unless overridden by a -drvopt flag.  I think the
default visual makes for a fine default, probably more useful than the way we
do it now.  And the -drvopt support means that one can always "fix" it at
runtime, or at least debug it easier.  In addition for displays that support
multiple visuals it is a nice plus to the user to be able to select it at
runtime.  Should probably provide a configuration option to use the legacy
approach, but also in that case have it be overridden by use of -drvopt.

Anyway, I'd planned on doing this work nearly a year ago, and am now much
busier than I was then, so if someone else wants to take a whack at it please
feel free.

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

Re: [Plplot-devel] Two issues

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

Joao Cardoso <jc...@fe...> wrote:
] 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.


I can't get xwin to work on two of my systems.  I'm motivated to get it
working and will give you any assistance i can in fixing it.




] 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?


Here's the screen info from xdpyinfo on the two systems that dont work
with xwin:


Machine 1
ATI Radeon Mobility 9000
XFree86 4.2.1 running in VESA mode

    screen #0:
      dimensions:    1600x1200 pixels (301x231 millimeters)
      resolution:    135x132 dots per inch
      depths (7):    24, 1, 4, 8, 15, 16, 32
      root window id:    0x36
      depth of root window:    24 planes
      number of colormaps:    minimum 1, maximum 1
      default colormap:    0x20
      default number of colormap cells:    256
      preallocated pixels:    black 0, white 16777215
      options:    backing-store NO, save-unders NO
      largest cursor:    1600x1200
      current input event mask:    0x5a20bd
        KeyPressMask             ButtonPressMask          ButtonReleaseMask
        EnterWindowMask          LeaveWindowMask          PointerMotionHintMask
        ButtonMotionMask         StructureNotifyMask      SubstructureNotifyMask
        SubstructureRedirectMask PropertyChangeMask
      number of visuals:    2
      default visual id:  0x22
      visual:
        visual id:    0x22
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x23
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits




Machine 2
nVidia GeForce 2 Go
XFree86 4.1.0.1

    screen #0:
      dimensions:    1024x768 pixels (292x222 millimeters)
      resolution:    89x88 dots per inch
      depths (7):    24, 1, 4, 8, 15, 16, 32
      root window id:    0x70
      depth of root window:    24 planes
      number of colormaps:    minimum 1, maximum 1
      default colormap:    0x20
      default number of colormap cells:    256
      preallocated pixels:    black 0, white 16777215
      options:    backing-store NO, save-unders NO
      largest cursor:    32x32
      current input event mask:    0x5a20bd
        KeyPressMask             ButtonPressMask          ButtonReleaseMask
        EnterWindowMask          LeaveWindowMask          PointerMotionHintMask
        ButtonMotionMask         StructureNotifyMask      SubstructureNotifyMask
        SubstructureRedirectMask PropertyChangeMask
      number of visuals:    16
      default visual id:  0x21
      visual:
        visual id:    0x21
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x22
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x23
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x24
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x25
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x26
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x27
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x28
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x29
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x2a
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x2b
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x2c
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x2d
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x2e
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x2f
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x30
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits




And here's one of my machines that work, just because:
i810
XFree86 4.2.1

    screen #0:
      dimensions:    1024x768 pixels (302x232 millimeters)
      resolution:    86x84 dots per inch
      depths (7):    24, 1, 4, 8, 15, 16, 32
      root window id:    0x3a
      depth of root window:    24 planes
      number of colormaps:    minimum 1, maximum 1
      default colormap:    0x20
      default number of colormap cells:    256
      preallocated pixels:    black 0, white 16777215
      options:    backing-store NO, save-unders NO
      largest cursor:    64x64
      current input event mask:    0xf84033
        KeyPressMask             KeyReleaseMask           EnterWindowMask
        LeaveWindowMask          KeymapStateMask          SubstructureNotifyMask
        SubstructureRedirectMask FocusChangeMask          PropertyChangeMask
        ColormapChangeMask
      number of visuals:    4
      default visual id:  0x23
      visual:
        visual id:    0x23
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x24
        class:    TrueColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x25
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits
      visual:
        visual id:    0x26
        class:    DirectColor
        depth:    24 planes
        available colormap entries:    256 per subfield
        red, green, blue masks:    0xff0000, 0xff00, 0xff
        significant bits in color specification:    8 bits




So they all have multiple visuals, even the one that works.  Not sure
if that's relevant.




I tried enabling USE_DEFAULT_VISUAL in xwin.c like you suggested.
I added a line that said "#define USE_DEFAULT_VISUAL" to right under
the comment that talks about it and recompiled.  Had a minor build
problem, it's missing Build-Depends on g++.  Installed the new packages.
Recompiled the examples, probably unnecessary since it's dynamically
linked but hey.  Anyway, it still didnt work, same problem as before.
"x07c -verbose -debug -dev xwin" says this (on the machine with the ATI):

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
(window is created & immediately destroyed, then i hit ^C)




All the other drivers i've tried work fine: gnome, tk, ntk, png...




Let me know if you want me to try anything else....




--
Sebastian