Re: [Plplot-general] Problem with color map1 and the tk driver

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

Dean Clamons writes:
 > I found that when I ran the demo x08c with the tk driver it blew up. With a 
 > little work I traced the problem to the call to plscmap1. Then after a lot more 
 > work I found that the problem is in plr.c.  In routine plr_state in the 
 > PLSTATE_CMAP1 case ot the switch there is no check made to see if the requested 
 > number of colors has been allocated in cmap1. It needs to be changed to 
 > something like:

It's not up to plr_state to determine this kind of thing; that's the driver's
responsibility.  It must honor the caller's wishes and allocate the colormap
regardless of the driver.

The driver then maps this onto something it can handle.  In this case, it
ultimately lands in the X driver.  The X driver allocates its own private copy
of cmap1 the first time it's used.  After that, changes to the internal plplot
color map only change the value of the X color cells.  Interpolation is used
to get a linear best fit.  See xwin.c/AllocCmap1() for more info.

 > In the process of finding this bug I found some problems with the debugging 
 > routines supplied. First the pldebug routine does not print the correct line 
 > and file - it always prints the same line number in the file pldebug.h. In 
 > order to fix this problem I changed the calling sequence to pldebug to pass in 
 > the line and file. The call would look something like:
 > 
 >         pldebug( __LINE__, __FILE__, "plr_state", "PLSTATE_CMAP1\n" );

I noticed that recently too and for 5.0.2 subtantially reworked the debugging
support.  __LINE__ & __FILE__ aren't in there, I almost put them in explicitly
as you write, but in the end decided that most of the uses didn't need it so
now it's left up to the caller to insert a descriptive tag.

I believe the previous pldebug behavior worked fine under HPUX (my old dev
platform), I guess cpp differences.  

 > I also found that it was difficult to find out what was going on on the server, 
 > so I added some options to the run parameters:
 > 
 > -debugfile name - causes any debug output to go to the file "name". By default 
 > it goes to stderr.
 > 
 > -sdebug - causes the program to run the server with the -debug option so that 
 > debugging output will happen on the server
 > 
 > -sdebugfile name - similar to -debugfile but it is passed to the server

Interesting.. yeah these could be handy.

-- 
Maurice LeBrun    mj...@ga...