plplot-devel — Technical discussion about PLplot development

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

What you need to do to make this all seamless now is install everything
that Plplot wants in a place where Tcl can see it through its normal
package mechanism.

This means you want to install a bunch of stuff into the directory
returned by:

wish
% file join [file dirname [info library]] plplot5.1.0

perhaps /usr/local/tcl/lib/plplot5.1.0 or something like that?

Anyway, the stuff that goes in there is:  (see sys/win-tk/makefile.vc's
'install' target for details):

*.map
*.fnt
tk/plcolor.tcl
tk/plplot.tcl
tk/pldefaults.tcl
tk/pltools.tcl
tk/plwidget.tcl
tk-x-plat/*.tcl
tk-x-plat/tclIndex

as well as the shared library you have created.

You may also need to edit 'pkgIndex.tcl' so that this stuff:

if {[info exists tcl_platform(debug)]} {
    set file [file join $dir plplot510d[info sharedlibextension]]
} else {
    set file [file join $dir plplot510[info sharedlibextension]]
}

Assuming you install all of this, then you should just be able to do:

wish
% package require Plplotter
5.1.0
% plframe .p 
.p
% pack .p

or simply:

wish runAllDemos.tcl

cheers,

Vince.

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

Ok, that basically means it worked.  Ignore that error and continue with
the source runAllDemos.tcl...

-- Vince

<http://www.santafe.edu/~vince>


On Thu, 11 Jul 2002, Alan W. Irwin wrote:

> On Thu, 11 Jul 2002, Vince Darley wrote:
> 
> > Ok, done everything else.
> 
> Thanks.  It still builds fine, and there is now a smooth error exit if
> you try to use the driver inappropriately.
> 
> > You need to build a shared library with contains all of the code.  Then
> > start up 'wish' (the tk shell) and type:
> >
> > >wish
> >
> > % cd location/of/my/shared/lib
> > % load nameOfSharedLib.so Plplotter
> > (assuming that doesn't return an error message)
> 
> Linux builds both static and shared library versions:
> 
> cd plplot/tmp
> ls -l libplplot*
> -rw-r--r--    1 software software  3010606 Jul 11 07:35 libplplotd.a
> lrwxrwxrwx    1 software software       15 Jul 11 07:36 libplplotd.so -> libplplotd.so.5*
> lrwxrwxrwx    1 software software       19 Jul 11 07:36 libplplotd.so.5 -> libplplotd.so.5.1.0*
> -rwxr-xr-x    1 software software  1279373 Jul 11 07:36 libplplotd.so.5.1.0*
> 
> wish
> % load libplplotd.so Plplotter
> invalid command name "pldefaults"
> 
> So it seems to be finding the library, but something is wrong with the
> initialization procedure that is invoked by Plplotter.  BTW, I get the same
> message if I use "load libplplotd.so" (with Plplotter dropped) instead or
> if I use the full name libplplotd.so.5.1.0 instead of the symlink.
> 
> Alan
> 
> 

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

On Thu, 11 Jul 2002, Vince Darley wrote:

> Ok, done everything else.

Thanks.  It still builds fine, and there is now a smooth error exit if
you try to use the driver inappropriately.

> You need to build a shared library with contains all of the code.  Then
> start up 'wish' (the tk shell) and type:
>
> >wish
>
> % cd location/of/my/shared/lib
> % load nameOfSharedLib.so Plplotter
> (assuming that doesn't return an error message)

Linux builds both static and shared library versions:

cd plplot/tmp
ls -l libplplot*
-rw-r--r--    1 software software  3010606 Jul 11 07:35 libplplotd.a
lrwxrwxrwx    1 software software       15 Jul 11 07:36 libplplotd.so -> libplplotd.so.5*
lrwxrwxrwx    1 software software       19 Jul 11 07:36 libplplotd.so.5 -> libplplotd.so.5.1.0*
-rwxr-xr-x    1 software software  1279373 Jul 11 07:36 libplplotd.so.5.1.0*

wish
% load libplplotd.so Plplotter
invalid command name "pldefaults"

So it seems to be finding the library, but something is wrong with the
initialization procedure that is invoked by Plplotter.  BTW, I get the same
message if I use "load libplplotd.so" (with Plplotter dropped) instead or
if I use the full name libplplotd.so.5.1.0 instead of the symlink.

Alan

[Plplot-devel] Re: tkwin build succeeded. Now need a way to test it

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

>>>
(2) How do I test the tkwin driver in a tk environment?  (Complete
cookbook
please since I have very little knowledge of tcl/tk).
>>>

Ok, done everything else.  Now to look at the above.

You need to build a shared library with contains all of the code.  Then
start up 'wish' (the tk shell) and type:

>wish

% cd location/of/my/shared/lib
% load nameOfSharedLib.so Plplotter
(assuming that doesn't return an error message)
% package provide Plplotter 5.1.0
% source location/of/runAllDemos.tcl

(hope that makes sense to you).  Obviously if the above works, then the
idea is that it can all be made very seamless but for the moment a manual
approach should tell us where (if) there are errors/problems.

-- Vince

<http://www.santafe.edu/~vince>

[Plplot-devel] tkwin build succeeded. Now need a way to test it

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

On Wed, 10 Jul 2002, Vince Darley wrote:

> I'm away from my machine at the moment, but just rename all instances of
> that function in Plplotter_Init.c and you should be ok.

I did this locally, but you probably wouldn't like my name (;-) so please
commit your solution to the nameclash when you have time.

With this change and adding

-I/usr/include/tcl8.3/tk-private/generic/
-DHAVE_LIMITS_H -I/usr/include/tcl8.3/tcl-private/generic/

by hand to the plplotter.c compile line, I finally got a good Linux build!

Now on to the executable testing.

I get a segfault if I try

./x01c -dev tkwin

Further debugging with the aid of valgrind showed the following problem
right before the segfault.

#2  0x4029e2c1 in plD_open_tkwin (pls=0x402bb040) at tkwin.c:427
427             tkwd->map = Tk_Colormap(pls->plPlotterPtr->tkwin);
(gdb) p pls->plPlotterPtr
$1 = (struct PlPlotter *) 0x0
(gdb) p pls->plPlotterPtr->tkwin
Cannot access memory at address 0x0

However, further reading of your code comments indicates this driver is only
supposed to work in a tk environment so I guess I deserved what I got....;-)

So two quick questions/comments:

(1) Please put in a quick test in tkwin.c that you *are* in a tk environment
so you get an error message and smooth exit (rather than segfault) when you
try this outside tk, e.g., with x01c.

(2) How do I test the tkwin driver in a tk environment?  (Complete cookbook
please since I have very little knowledge of tcl/tk).

Alan

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

I'm away from my machine at the moment, but just rename all instances of
that function in Plplotter_Init.c and you should be ok.

-- Vince

<http://www.santafe.edu/~vince>


On Wed, 10 Jul 2002, Alan W. Irwin wrote:

> On Wed, 10 Jul 2002, Vince Darley wrote:
> 
> > On Wed, 10 Jul 2002, Alan W. Irwin wrote:
> >
> > > plplotter.c: In function PlPlotterKeyEH':
> > > plplotter.c:1290: TkWindow' undeclared (first use in this function)
> > > plplotter.c:1290: (Each undeclared identifier is reported only once
> > > plplotter.c:1290: for each function it appears in.)
> > > plplotter.c:1290: parse error before )'
> > > plplotter.c: In function Openlink':
> > > plplotter.c:2529: O_RDONLY' undeclared (first use in this function)
> >
> > O_RDONLY should be in some standard Unix header file (posix headers), and
> > I'm afraid that 'TkpWindow((TkWindow*)...)' shows why this file actually
> > does need tkInt.h
> 
> Thanks to Joao's tip on O_RDONLY and (by hand) adding the flags
> 
> -I/usr/include/tcl8.3/tk-private/generic/ -DHAVE_LIMITS_H
> -I/usr/include/tcl8.3/tcl-private/generic/
> 
> I got plplotter.c compiled and put into the library.  However, now run
> into a library nameclash for plWait_Until.
> 
> Building shared library
> 
> cd shared; \
> gcc -shared -fPIC -o ../libplplotd.so.5.1.0 \
>         -Wl,-soname -Wl,libplplotd.so.5 \
> 	        pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o
> plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o
> plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o
> plimage.o tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o Plplotter_Init.o
> plplotter.o xwin.o tk.o tkwin.o sc3d.o sccont.o scstubs.o  javabind.o
> tclMain.o  tkMain.o  strutil.o sfstubs.o  -L.. -ltclmatrixd -litk3.1 -ltk8.3
> -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -lg2c
> Plplotter_Init.o: In function plWait_Until':
> Plplotter_Init.o(.text+0x8c): multiple definition of plWait_Until'
> Pltk_Init.o(.text+0xcc): first defined here
> collect2: ld returned 1 exit status
> 
> Looking forward to the next iteration from you....
> 
> Alan
> 
> 

Re: [Plplot-devel] Problems with setting cmap0 and cmap1 for the xfig and png devices

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

On Wed, 10 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> the xfig file format stores colors at a fixed position (variable length)
> in the begining of the file; latter changes in the colors will thus
> overwrite the previous color setting, thus the observed results.

Thanks for investigating this case.  However, I don't see how the position
of where the colours are stored in the file matters so long as you are
allowed to add to the colours part way through a plot, and I assume your
variable length remark means you can do that for the xfig format.

Of course this is not a trivial fix.  What you have to do is to have an
additional mapping step to get from the PLplot colours to the xfig ones.  T=
o
take the cmap0 example a step further for the first sub-plot there are 16
PLplot colours which should be mapped to 16 xfig colours. However, when the
first colour index for PLplot cmap0 is changed from red to white for the
remaining sub-plots then there should be an additional 17th white colour
defined in the xfig system which the first cmap0 index for PLplot now maps
to.  But the red colour is still in the xfig colour map so the first
sub-plot with red box and scales should remain unaffected.

>
> I think the same happens for any file based format, and can't be fixed.

No, I don't believe you can generalize this way.  There is no such problem
with the postscript format.  Furthermore, I believe the idea of having a
transformation between the PLplot colour maps and the file device colour ma=
p
as above should solve the problem for all devices which allow you to add to
their colour map part way through a plot.  I believe from what you have
said above this should be possible for the xfig format, and that also seems
to be the case for the libgd format (upon which the png and jpeg devices
are based).

Of course it is easy to sit here and theorize about a solution that will
take considerable work on your part to implement, and I fully understand if
you (or Andrew) don't have time/inclination to deal with this now. But the
current situation is (I believe) that xfig and the libgd-based drivers make
the simplistic assumption that there is a constant one-to-one transformatio=
n
between the PLplot colour maps and the device colour map.  If you do the
work to remove this assumption as above, then the xfig and png plots for th=
e
octave, tcl, and python front ends (which do several examples at a time)
will not have the colour map cross-talk that now occurs.  This will bring
these devices' colour map behaviour finally into line with what occurs for
the psc device which would be a Good Thing....

Alan

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

On Wed, 10 Jul 2002, Vince Darley wrote:

> On Wed, 10 Jul 2002, Alan W. Irwin wrote:
>
> > plplotter.c: In function PlPlotterKeyEH':
> > plplotter.c:1290: TkWindow' undeclared (first use in this function)
> > plplotter.c:1290: (Each undeclared identifier is reported only once
> > plplotter.c:1290: for each function it appears in.)
> > plplotter.c:1290: parse error before )'
> > plplotter.c: In function Openlink':
> > plplotter.c:2529: O_RDONLY' undeclared (first use in this function)
>
> O_RDONLY should be in some standard Unix header file (posix headers), and
> I'm afraid that 'TkpWindow((TkWindow*)...)' shows why this file actually
> does need tkInt.h

Thanks to Joao's tip on O_RDONLY and (by hand) adding the flags

-I/usr/include/tcl8.3/tk-private/generic/ -DHAVE_LIMITS_H
-I/usr/include/tcl8.3/tcl-private/generic/

I got plplotter.c compiled and put into the library.  However, now run
into a library nameclash for plWait_Until.

Building shared library

cd shared; \
gcc -shared -fPIC -o ../libplplotd.so.5.1.0 \
        -Wl,-soname -Wl,libplplotd.so.5 \
	        pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o
plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o
plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o
plimage.o tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o Plplotter_Init.o
plplotter.o xwin.o tk.o tkwin.o sc3d.o sccont.o scstubs.o  javabind.o
tclMain.o  tkMain.o  strutil.o sfstubs.o  -L.. -ltclmatrixd -litk3.1 -ltk8.3
-litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -lg2c
Plplotter_Init.o: In function plWait_Until':
Plplotter_Init.o(.text+0x8c): multiple definition of plWait_Until'
Pltk_Init.o(.text+0xcc): first defined here
collect2: ld returned 1 exit status

Looking forward to the next iteration from you....

Alan

Re: [Plplot-devel] Problems with setting cmap0 and cmap1 for the xfig and png devices

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

On Saturday 06 July 2002 01:47, Alan W. Irwin wrote:
| Try the following experiment:
|
| Make a special copy of x01c (or xw01.py, which is what I used) which
| calls plscol0(1,255,255,255) between the first and second calls to
| plot1.  The plscol0 call sets index 1 of cmap0 to white rather than
| the default red.
|
| If you use interactive devices such as xwin, tk, ntk, etc. you get
| the expected result; the first subplot of example 1 continues to have
| a red box, red scales, etc., and the remaing sub-plots have white
| boxes and scales.
|
| For the psc (colour postgrip) device the same result also occurs;
| the first sub-plot has red box and scales, and the remaining subplots
| have white box and scales.
|
| However, for the xfig and png devices *all* the subplots unexpectedly
| have white box and scales.  So if you change color indices part way
| through a plot, the earlier part of the plot is retroactively changed
| for those drivers!
|
| The simple example I gave was for the discrete colours (cmap0), but I
| am getting the same result for example 8 for the png driver with the
| continuous colours (cmap1), and the results look quite bad.  At the
| end of that example (which uses a gray-scale cmap1), I set cmap1 back
| to the default before going on with plotting other plots for the tcl
| and python front ends.  (If I don't do this, example 16 becomes gray
| scale rather than the desired default colours since python and tcl
| run all examples under a common plinit.) This procedure of resetting
| to default cmap1 works well for the psc device, but for the xfig and
| png devices, resetting cmap1 to the default at the end retroactively
| changes the whole continuous color map of example 8 back to default
| (rather than leaving it at the desired gray scale).
|
| So for both the xfig and png devices (and presumbably jpeg as well)
| we have a nasty "retroactivity" problem with any attempt to change
| either cmap0 or cmap1 part way through a plot.
|
| Joao and Andrew, would you be willing to have a look at this problem
| for your drivers (xfig.c for Joao and gd.c for Andrew) and fix it?

the xfig file format stores colors at a fixed position (variable length)=20
in the begining of the file; latter changes in the colors will thus=20
overwrite the previous color setting, thus the observed results.

I think the same happens for any file based format, and can't be fixed.

Jo=E3o

|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Bringing you mounds of caffeinated joy.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

On Wednesday 10 July 2002 16:09, Vince Darley wrote:
| On Wed, 10 Jul 2002, Alan W. Irwin wrote:
| > plplotter.c: In function PlPlotterKeyEH':
| > plplotter.c:1290: TkWindow' undeclared (first use in this function)
| > plplotter.c:1290: (Each undeclared identifier is reported only once
| > plplotter.c:1290: for each function it appears in.)
| > plplotter.c:1290: parse error before )'
| > plplotter.c: In function Openlink':
| > plplotter.c:2529: O_RDONLY' undeclared (first use in this function)
|
| O_RDONLY should be in some standard Unix header file (posix headers),

#include <fcntl.h>

| and I'm afraid that 'TkpWindow((TkWindow*)...)' shows why this file
| actually does need tkInt.h
|
| cheers,
|
| Vince.
|
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Two, two, TWO treats in one.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

On Wed, 10 Jul 2002, Alan W. Irwin wrote:

> plplotter.c: In function PlPlotterKeyEH':
> plplotter.c:1290: TkWindow' undeclared (first use in this function)
> plplotter.c:1290: (Each undeclared identifier is reported only once
> plplotter.c:1290: for each function it appears in.)
> plplotter.c:1290: parse error before )'
> plplotter.c: In function Openlink':
> plplotter.c:2529: O_RDONLY' undeclared (first use in this function)

O_RDONLY should be in some standard Unix header file (posix headers), and
I'm afraid that 'TkpWindow((TkWindow*)...)' shows why this file actually
does need tkInt.h

cheers,

Vince.

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

On Wed, 10 Jul 2002, Vince Darley wrote:

> Ok, I've fixed those remaining issues.  Make sure you are compiling
> plplotter.c and Plplotter_Init.c as well as tkwin.c

I am getting a lot further now.  Without plplotter.c and Plplotter_Init.c
all is well with the library build, but of course there are some undefined
symbols related to those two when trying to link executables with the library.

So as suggested by you I included compilation of plplotter.c and
Plplotter_Init.c in the library.  Plplotter_Init.c compiles cleanly, but
there are compilation errors for plplotter.c.

plplotter.c: In function PlPlotterKeyEH':
plplotter.c:1290: TkWindow' undeclared (first use in this function)
plplotter.c:1290: (Each undeclared identifier is reported only once
plplotter.c:1290: for each function it appears in.)
plplotter.c:1290: parse error before )'
plplotter.c: In function Openlink':
plplotter.c:2529: O_RDONLY' undeclared (first use in this function)

I cannot figure this out so I hope you have some ideas about what is missing
on the Linux side.

Alan

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

Ok, I've fixed those remaining issues.  Make sure you are compiling
plplotter.c and Plplotter_Init.c as well as tkwin.c

-- Vince

<http://www.santafe.edu/~vince>

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

On Wed, 10 Jul 2002, Vince Darley wrote:

> > (2) Your code depends on tkInt.h which is an internal header used by Tk
> > which is supposedly not for public use.  (This is very similar to the
> > distinction we make between common and public API.) Presumably, you are
> > using some internal Tk API, which they did not want you to use.
>
> It is not that "they did not want me to use", just that Tk's internal API
> includes a bunch of X emulation stuff which is needed by the widget.  It
> is conceivable that on unix only it might compile with only tk.h (feel
> free to try), but on Windows/MacOS tkInt.h is 100% required.

OK, I did try tk.h, and it builds without warnings or errors, but I haven't
yet been able to test it at run time (see below).

>
> I think I've fixed the remaining issues you reported. (warnings, name
> clashes etc).

Thanks very much for this effort.  The compile warnings are indeed gone,
and most of the linker errors.  However, there is still one left (presumably
because plplot_ccmap means different things in xwin.c and tkwin.c).

cd shared; \
gcc -shared -fPIC -o ../libplplotd.so.5.1.0 \
        -Wl,-soname -Wl,libplplotd.so.5 \
	        pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o
plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o
plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o
plimage.o tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o xwin.o tk.o tkwin.o
sc3d.o sccont.o scstubs.o  javabind.o tclMain.o  tkMain.o  strutil.o
sfstubs.o  -L.. -ltclmatrixd -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3
-L/usr/X11R6/lib -lX11 -ldl -lm -lg2c
tkwin.o(.data+0x4): multiple definition of plplot_ccmap'
xwin.o(.data+0x8): first defined here
collect2: ld returned 1 exit status
make: *** [libplplotd.so.5.1.0] Error 1

As soon as this is sorted out, I look forward to some run-time testing.

Alan

Re: [Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

On Tue, 9 Jul 2002, Alan W. Irwin wrote:
> (1) pltools.tcl and plwidget.tcl nameclash between files in tk and tk-x-plat.
> Could you please rename the tk-x-plat files to something else so the tk
> driver can comfortably coexist with yours?  My workaround was to locally
> symlink those files when I needed them, but that is not a general
> solution since it clobbers the tk driver.

I've removed pltools.tcl, and will soon remove plwidget.tcl, after
synchronising the changes with the tk version.

> (2) Your code depends on tkInt.h which is an internal header used by Tk
> which is supposedly not for public use.  (This is very similar to the
> distinction we make between common and public API.) Presumably, you are
> using some internal Tk API, which they did not want you to use.  

It is not that "they did not want me to use", just that Tk's internal API
includes a bunch of X emulation stuff which is needed by the widget.  It
is conceivable that on unix only it might compile with only tk.h (feel
free to try), but on Windows/MacOS tkInt.h is 100% required.

I think I've fixed the remaining issues you reported. (warnings, name
clashes etc).

thank!

Vince.

[Plplot-devel] current tkwin device cannot be built on Linux because of name clashes

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

Vince,

Joao told me privately, and I confirmed that you cannot build the tkwin
device in its present state on Linux.  However, once some nameclashes are
resolved it might work.

For other Linux users who might be interested in trying this,
to attempt access to this device simply add the configuration
option --with-tkwin

I have just made some commits to fix up some minor problems (the worst being
the incorrect device number which should be 45 and not 44).

Here are some additional problems which I could workaround:

(1) pltools.tcl and plwidget.tcl nameclash between files in tk and tk-x-plat.
Could you please rename the tk-x-plat files to something else so the tk
driver can comfortably coexist with yours?  My workaround was to locally
symlink those files when I needed them, but that is not a general
solution since it clobbers the tk driver.

(2) Your code depends on tkInt.h which is an internal header used by Tk
which is supposedly not for public use.  (This is very similar to the
distinction we make between common and public API.) Presumably, you are
using some internal Tk API, which they did not want you to use.  Is there
some alternative from their more normal API which you could use instead so
you could drop tkInt.h altogether?  Many Linux distributions (such as SuSe
used by Joao) do not have this internal header file.  Debian woody happens
to include the private headers so I worked around the problem by local
changes to my Makefile to put the following on the compile line:

-I /usr/include/tcl8.3/tk-private/generic/ -DHAVE_LIMITS_H

But this will be impossible for most other distributions so a better solution
is to drop the dependence on tkInt.h (and private Tk functions) altogether.

Note, there were some compilation warnings with this fix which you may want
to address:

plplot/pltkwd.h:160: warning: struct PlFrame' declared inside parameter list
plplot/pltkwd.h:160: warning: its scope is only this definition or
declaration, which is probably not what you want

Finally, we come to the showstopper which is lots of link errors due to
nameclashes with the xwin driver:

cd tmp; make default
make[1]: Entering directory `/home/software/plplot_cvs/HEAD/plplot_working3/tmp'
rm -f libplplotd.so.5.1.0

Building shared library

cd shared; \
gcc -shared -fPIC -o ../libplplotd.so.5.1.0 \
	-Wl,-soname -Wl,libplplotd.so.5 \
	pdfutils.o plargs.o plbox.o plbuf.o plcont.o plcore.o plctrl.o plcvt.o pldtik.o plfill.o plhist.o plline.o plmap.o plot3d.o plpage.o plsdef.o plshade.o plsym.o pltick.o plvpor.o plwind.o plstripc.o plimage.o tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o xwin.o tk.o tkwin.o sc3d.o sccont.o scstubs.o  javabind.o tclMain.o  tkMain.o  strutil.o sfstubs.o  -L.. -ltclmatrixd -litk3.1 -ltk8.3 -litcl3.1 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -lg2c
tkwin.o(.data+0x4): multiple definition of `plplot_ccmap'
xwin.o(.data+0x8): first defined here
tkwin.o: In function `plX_setBGFG':
tkwin.o(.text+0x1650): multiple definition of `plX_setBGFG'
xwin.o(.text+0x2b9c): first defined here
/usr/bin/ld: Warning: size of symbol `plX_setBGFG' changed from 264 to 209 in tkwin.o
tkwin.o: In function `PLColor_to_XColor':
tkwin.o(.text+0x1a24): multiple definition of `PLColor_to_XColor'
xwin.o(.text+0x3704): first defined here
tkwin.o: In function `PLColor_from_XColor':
tkwin.o(.text+0x1a64): multiple definition of `PLColor_from_XColor'
xwin.o(.text+0x3744): first defined here
tkwin.o: In function `PLX_save_colormap':
tkwin.o(.text+0x1af8): multiple definition of `PLX_save_colormap'
xwin.o(.text+0x37c0): first defined here
/usr/bin/ld: Warning: size of symbol `PLX_save_colormap' changed from 95 to 89 in tkwin.o
collect2: ld returned 1 exit status
make[1]: *** [libplplotd.so.5.1.0] Error 1
make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/plplot_working3/tmp'
make: *** [all] Error 2

Again, these all look like name clashes with definitions in xwin.c
which have to be resolved so the two can peacefully coexist.

Once the two sets of nameclashes are taken care of, I will be happy to try
again with the -I /usr/include/tcl8.3/tk-private/generic/ -DHAVE_LIMITS_H
workaround just to see how far I can get.

Alan

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

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Janitorial help needed to fix memory leaks in plplot

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

On Mon, 8 Jul 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Friday 05 July 2002 21:17, Alan W. Irwin wrote:
> | I have just looked deeper into the memory leaks for x01c -dev psc
> | reported by valgrind with valgrind option --leak-resolution=3Dhigh.  1
> | of them was a problem with glibc fopen, 3 of them were problems with
> | glibc ctime, 5 of them were problems with glibc dlopen, and the
> | remaining 14 (of 23 total under high resolution) all occur in
> | plinitDispatchTable.
> |
> | plinitDispatchTable calls plstrdup at lines 1643, 1644, 1657-1660,
> | and 1674. Non of those are freed again,
>
> The problem with plstrdup() is that you don't know when/if you can free
> the allocated memory; if the duplicated string pointer is stored in a
> global variable or structure, then you can't know where/when will it be
> needed again.

I agree you could not do it from plstrdup itself.  As that function makes
clear it is the responsibility of the caller to free the memory again, but
the current code does not do that.

>
> | and the 1643 and 1644
> | pointers are eventually lost (and those lines are called twice)
> | according to valgrind. I am wondering if the lost pointers are due to
> | using the same structure for static and dynamic drivers or whether
> | there is a misconfiguration of driver number for my particular
> | configuration?  (I configured with
> | --enable-dyndrivers --enable-gnome --enable-ntk).
> |
> | plinitDispatchTable also calls malloc at lines 1591, 1601, 1613,
> | 1614, and 1640.  None of those are freed.
>
> They could probably be freed when plend() or plend1() are called, this
> is, when the driver is closed.
>
> =3D=3D26486=3D=3D    definitely lost: 28 bytes in 2 blocks.
> =3D=3D26486=3D=3D    possibly lost:   0 bytes in 0 blocks.
> =3D=3D26486=3D=3D    still reachable: 6702 bytes in 225 blocks.
>
> I have only used valgrind a few times, but the final report makes me
> belive that the "still reachable:" line means that those are global
> variables, and could only be freed at plend/1, which most of the case
> is not a leak, as most of the time the program finish after that point
> (but could be fixed anyway). The "definitely lost" line probably means
> a real leak, as the pointers to the memory are lost.

I don't wish to be too fanatical about the "still reachable" ones, although
I think we should free stuff explicitly if it is straightforward to do so
simply to clarify our code. Geoffrey, is is straightforward?

The lost ones are a more urgent problem.  Geoffrey, do you expect those
particular pointers to be lost or is this some evidence of a bug (or
misconfiguration, say, if we have overlapping device numbers)?

I have now done some much more extensive valgrind checks.

I have done all our usual testing examples (excluding 14, 17, 19, and 20)
for psc and png using the C front end and also png for the python front end=
=2E
I did encounter one memory mismanagement problem (attempted memory access
from uninitialized static area or outside a dynamically allocated area)
which I fixed so plplot is now valgrind clean in this respect.

I also did the leak check (as opposed to memory mismanagement check) for a
complete python run of all examples using png.  No new plplot free memory
problems surfaced beyond the ones I have already indicated for
plInitDispatchTable. So once we get rid of those, plplot will be completely
valgrind clean (at least for the examples/device combinations I have tried)=
=2E

Alan

Re: [Plplot-devel] Janitorial help needed to fix memory leaks in plplot

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

On Friday 05 July 2002 21:17, Alan W. Irwin wrote:
| I have just looked deeper into the memory leaks for x01c -dev psc
| reported by valgrind with valgrind option --leak-resolution=3Dhigh.  1
| of them was a problem with glibc fopen, 3 of them were problems with
| glibc ctime, 5 of them were problems with glibc dlopen, and the
| remaining 14 (of 23 total under high resolution) all occur in
| plinitDispatchTable.
|
| plinitDispatchTable calls plstrdup at lines 1643, 1644, 1657-1660,
| and 1674. Non of those are freed again,

The problem with plstrdup() is that you don't know when/if you can free=20
the allocated memory; if the duplicated string pointer is stored in a=20
global variable or structure, then you can't know where/when will it be=20
needed again.

| and the 1643 and 1644
| pointers are eventually lost (and those lines are called twice)
| according to valgrind. I am wondering if the lost pointers are due to
| using the same structure for static and dynamic drivers or whether
| there is a misconfiguration of driver number for my particular
| configuration?  (I configured with
| --enable-dyndrivers --enable-gnome --enable-ntk).
|
| plinitDispatchTable also calls malloc at lines 1591, 1601, 1613,
| 1614, and 1640.  None of those are freed.

They could probably be freed when plend() or plend1() are called, this=20
is, when the driver is closed.

=3D=3D26486=3D=3D    definitely lost: 28 bytes in 2 blocks.
=3D=3D26486=3D=3D    possibly lost:   0 bytes in 0 blocks.
=3D=3D26486=3D=3D    still reachable: 6702 bytes in 225 blocks.

I have only used valgrind a few times, but the final report makes me=20
belive that the "still reachable:" line means that those are global=20
variables, and could only be freed at plend/1, which most of the case=20
is not a leak, as most of the time the program finish after that point=20
(but could be fixed anyway). The "definitely lost" line probably means=20
a real leak, as the pointers to the memory are lost.

|  In any case I think some
| checks should go in after the mallocs to be sure the memory was
| allocated successfully.

Sure.

|
| Geoffrey, I am addressing this question to you since
| plinitDispatchTable was originally your code.  I would like to put
| the appropriate frees in plinitDispatchTable for the various plstrdup
| and malloc calls, but I am not sure of the right place to do this
| since I don't follow the code that easily.  Once a device has been
| chosen, is there any need for these memory areas? Please advise!

I'm not looking at the code, but if those addresses are referenced in=20
other places, then you can't free them. Remember also that more than=20
one device can be opened at the same time, e.g., when printing.

Joao

|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Bringing you mounds of caffeinated joy.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Problems with setting cmap0 and cmap1 for the xfig and png devices

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

Try the following experiment:

Make a special copy of x01c (or xw01.py, which is what I used) which calls
plscol0(1,255,255,255) between the first and second calls to plot1.  The
plscol0 call sets index 1 of cmap0 to white rather than the default red.

If you use interactive devices such as xwin, tk, ntk, etc. you get the
expected result; the first subplot of example 1 continues to have a red box,
red scales, etc., and the remaing sub-plots have white boxes and scales.

For the psc (colour postgrip) device the same result also occurs;
the first sub-plot has red box and scales, and the remaining subplots
have white box and scales.

However, for the xfig and png devices *all* the subplots unexpectedly have
white box and scales.  So if you change color indices part way through a
plot, the earlier part of the plot is retroactively changed for those
drivers!

The simple example I gave was for the discrete colours (cmap0), but I am
getting the same result for example 8 for the png driver with the continuous
colours (cmap1), and the results look quite bad.  At the end of that example
(which uses a gray-scale cmap1), I set cmap1 back to the default before
going on with plotting other plots for the tcl and python front ends.  (If I
don't do this, example 16 becomes gray scale rather than the desired default
colours since python and tcl run all examples under a common plinit.) This
procedure of resetting to default cmap1 works well for the psc device, but
for the xfig and png devices, resetting cmap1 to the default at the end
retroactively changes the whole continuous color map of example 8 back to
default (rather than leaving it at the desired gray scale).

So for both the xfig and png devices (and presumbably jpeg as well) we have
a nasty "retroactivity" problem with any attempt to change either cmap0 or
cmap1 part way through a plot.

Joao and Andrew, would you be willing to have a look at this problem for
your drivers (xfig.c for Joao and gd.c for Andrew) and fix it?

Alan

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

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Janitorial help needed to fix memory leaks in plplot

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

I have just looked deeper into the memory leaks for x01c -dev psc reported
by valgrind with valgrind option --leak-resolution=high.  1 of them was a
problem with glibc fopen, 3 of them were problems with glibc ctime, 5 of
them were problems with glibc dlopen, and the remaining 14 (of 23 total
under high resolution) all occur in plinitDispatchTable.

plinitDispatchTable calls plstrdup at lines 1643, 1644, 1657-1660, and 1674.
Non of those are freed again, and the 1643 and 1644 pointers are eventually
lost (and those lines are called twice) according to valgrind. I am
wondering if the lost pointers are due to using the same structure for
static and dynamic drivers or whether there is a misconfiguration of driver
number for my particular configuration?  (I configured with
--enable-dyndrivers --enable-gnome --enable-ntk).

plinitDispatchTable also calls malloc at lines 1591, 1601, 1613, 1614,
and 1640.  None of those are freed.  In any case I think some checks
should go in after the mallocs to be sure the memory was allocated
successfully.

Geoffrey, I am addressing this question to you since plinitDispatchTable was
originally your code.  I would like to put the appropriate frees in
plinitDispatchTable for the various plstrdup and malloc calls, but I am not
sure of the right place to do this since I don't follow the code that
easily.  Once a device has been chosen, is there any need for these memory
areas? Please advise!

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Janitorial help needed to fix memory leaks in plplot

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

I have just been running some tests with valgrind, and there are lots of
problems in the plplot core and in drivers with code that allocates memory
but which does not free it afterward.  In some cases even the pointer to the
memory area is lost by the time the example code exits.

All this stuff is fairly non-consequential since most users of plplot have
large memory at their disposal and these leaks are relatively modest.
Nevertheless, it would be nice to get this all cleaned up so we have clean
valgrind runs on all our examples for the C front end (the x??c examples), and
the psc device. Thus, I am calling for "janitorial" volunteers to
work on this with me.  It's a perfect part-time project; it shouldn't take
that long to remove one memory leak, and that one removal is a worthwhile
step in the right direction.  Once we have all the x??c examples running
valgrind clean with the psc device I intend to expand the project to other
front ends and other devices.

To give you an idea of the scale of the problem, I append below a typical
valgrind run which shows 16 different problems like this for x01c -dev psc.

BTW, to get the line numbers listed this way you must configure plplot
--with-debug=yes --with-opt=no

Also, I have to agree with the tone of prior remarks from Geoffrey and Joao;
valgrind is just an awesome tool for figuring out memory management problems
if you have access to a Linux x86 box.  The --gdb-attach=yes valgrind option
below allows you to jump immediately into gdb if your code ever attempts to
use uninitialized or freed memory (BTW, from the report below that
apparently is not a problem for x01c), and I have already used that option
to diagnose and quickly clean up some memory management problems that showed
up for the eighth example.

For more valgrind information see http://developer.kde.org/~sewardj/.

Alan

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

Linux-powered astrophysics
__________________________

valgrind --leak-check=yes --show-reachable=yes --gdb-attach=yes --num-callers=20 ./x01c -dev psc -o test.ps
==26486== valgrind-1.0pre2, a memory error detector for x86 GNU/Linux.
==26486== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==26486== Estimated CPU clock rate is 604 MHz
==26486== For more details, rerun with: -v
==26486==
Plplot library version: 5.1.0
Opened test.ps
==26486==
==26486== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
==26486== malloc/free: in use at exit: 6730 bytes in 227 blocks.
==26486== malloc/free: 240 allocs, 13 frees, 67950 bytes allocated.
==26486== For counts of detected errors, rerun with: -v
==26486== searching for pointers to 227 not-freed blocks.
==26486== checked 6586072 bytes.
==26486==
==26486== definitely lost: 28 bytes in 2 blocks.
==26486== possibly lost:   0 bytes in 0 blocks.
==26486== still reachable: 6702 bytes in 225 blocks.
==26486==
==26486== 15 bytes in 1 blocks are still reachable in loss record 1 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4059C39F: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BEEFF: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BFC1E: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BC8A2: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BC791: (within /lib/libc-2.2.5.so)
==26486==    by 0x402C2FE5: ps_getdate (ps.c:638)
==26486==    by 0x402C180E: ps_init (ps.c:178)
==26486==    by 0x402C158C: plD_init_psc (ps.c:101)
==26486==    by 0x402552C9: plP_init (plcore.c:58)
==26486==    by 0x40258653: c_plinit (plcore.c:1165)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 18 bytes in 1 blocks are still reachable in loss record 2 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x40005A9E: _dl_map_object (in /lib/ld-2.2.5.so)
==26486==    by 0x4061F9CA: (within /lib/libc-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FE07: (within /lib/libc-2.2.5.so)
==26486==    by 0x40505EE4: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x405062EF: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40505F1F: (within /lib/libdl-2.2.5.so)
==26486==    by 0x4025A02F: plLoadDriver (plcore.c:1840)
==26486==    by 0x4025937D: plGetDev (plcore.c:1534)
==26486==    by 0x40258649: c_plinit (plcore.c:1160)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 28 bytes in 2 blocks are definitely lost in loss record 3 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4025F0E8: plstrdup (plctrl.c:1722)
==26486==    by 0x40259775: plInitDispatchTable (plcore.c:1643)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 36 bytes in 3 blocks are still reachable in loss record 4 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x405BED70: (within /lib/libc-2.2.5.so)
==26486==    by 0x405C0415: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BEF2A: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BFC1E: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BC8A2: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BC791: (within /lib/libc-2.2.5.so)
==26486==    by 0x402C2FE5: ps_getdate (ps.c:638)
==26486==    by 0x402C180E: ps_init (ps.c:178)
==26486==    by 0x402C158C: plD_init_psc (ps.c:101)
==26486==    by 0x402552C9: plP_init (plcore.c:58)
==26486==    by 0x40258653: c_plinit (plcore.c:1165)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 80 bytes in 1 blocks are still reachable in loss record 5 of 16
==26486==    at 0x4004304F: calloc (vg_clientfuncs.c:221)
==26486==    by 0x4000ADED: _dl_check_map_versions (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FABE: (within /lib/libc-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FE07: (within /lib/libc-2.2.5.so)
==26486==    by 0x40505EE4: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x405062EF: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40505F1F: (within /lib/libdl-2.2.5.so)
==26486==    by 0x4025A02F: plLoadDriver (plcore.c:1840)
==26486==    by 0x4025937D: plGetDev (plcore.c:1534)
==26486==    by 0x40258649: c_plinit (plcore.c:1160)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 96 bytes in 2 blocks are still reachable in loss record 6 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4025952A: plInitDispatchTable (plcore.c:1601)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 100 bytes in 1 blocks are still reachable in loss record 7 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4000925D: _dl_map_object_deps (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FA86: (within /lib/libc-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FE07: (within /lib/libc-2.2.5.so)
==26486==    by 0x40505EE4: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x405062EF: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40505F1F: (within /lib/libdl-2.2.5.so)
==26486==    by 0x4025A02F: plLoadDriver (plcore.c:1840)
==26486==    by 0x4025937D: plGetDev (plcore.c:1534)
==26486==    by 0x40258649: c_plinit (plcore.c:1160)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 120 bytes in 1 blocks are still reachable in loss record 8 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x402594FB: plInitDispatchTable (plcore.c:1591)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 146 bytes in 1 blocks are still reachable in loss record 9 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x400430E4: realloc (vg_clientfuncs.c:244)
==26486==    by 0x40007E5D: _dl_new_object (in /lib/ld-2.2.5.so)
==26486==    by 0x4000443B: _dl_map_object_from_fd (in /lib/ld-2.2.5.so)
==26486==    by 0x40005C21: _dl_map_object (in /lib/ld-2.2.5.so)
==26486==    by 0x4061F9CA: (within /lib/libc-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FE07: (within /lib/libc-2.2.5.so)
==26486==    by 0x40505EE4: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x405062EF: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40505F1F: (within /lib/libdl-2.2.5.so)
==26486==    by 0x4025A02F: plLoadDriver (plcore.c:1840)
==26486==    by 0x4025937D: plGetDev (plcore.c:1534)
==26486==    by 0x40258649: c_plinit (plcore.c:1160)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 224 bytes in 1 blocks are still reachable in loss record 10 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x402595CC: plInitDispatchTable (plcore.c:1614)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 364 bytes in 1 blocks are still reachable in loss record 11 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4058A681: (within /lib/libc-2.2.5.so)
==26486==    by 0x40247B46: pdf_fopen (pdfutils.c:99)
==26486==    by 0x4025E096: plLibOpenPdfstrm (plctrl.c:1193)
==26486==    by 0x4025DF8E: plLibOpen (plctrl.c:1160)
==26486==    by 0x40259420: plInitDispatchTable (plcore.c:1567)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 454 bytes in 1 blocks are still reachable in loss record 12 of 16
==26486==    at 0x4004304F: calloc (vg_clientfuncs.c:221)
==26486==    by 0x40007CAF: _dl_new_object (in /lib/ld-2.2.5.so)
==26486==    by 0x4000443B: _dl_map_object_from_fd (in /lib/ld-2.2.5.so)
==26486==    by 0x40005C21: _dl_map_object (in /lib/ld-2.2.5.so)
==26486==    by 0x4061F9CA: (within /lib/libc-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x4061FE07: (within /lib/libc-2.2.5.so)
==26486==    by 0x40505EE4: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so)
==26486==    by 0x405062EF: (within /lib/libdl-2.2.5.so)
==26486==    by 0x40505F1F: (within /lib/libdl-2.2.5.so)
==26486==    by 0x4025A02F: plLoadDriver (plcore.c:1840)
==26486==    by 0x4025937D: plGetDev (plcore.c:1534)
==26486==    by 0x40258649: c_plinit (plcore.c:1160)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 560 bytes in 1 blocks are still reachable in loss record 13 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x402595A9: plInitDispatchTable (plcore.c:1613)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 976 bytes in 1 blocks are still reachable in loss record 14 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x405BFFF8: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BEF2A: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BFC1E: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BC8A2: (within /lib/libc-2.2.5.so)
==26486==    by 0x405BC791: (within /lib/libc-2.2.5.so)
==26486==    by 0x402C2FE5: ps_getdate (ps.c:638)
==26486==    by 0x402C180E: ps_init (ps.c:178)
==26486==    by 0x402C158C: plD_init_psc (ps.c:101)
==26486==    by 0x402552C9: plP_init (plcore.c:58)
==26486==    by 0x40258653: c_plinit (plcore.c:1165)
==26486==    by 0x8048ED2: main (x01c.c:114)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 1344 bytes in 28 blocks are still reachable in loss record 15 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4025974C: plInitDispatchTable (plcore.c:1640)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== 2169 bytes in 181 blocks are still reachable in loss record 16 of 16
==26486==    at 0x40042BDB: malloc (vg_clientfuncs.c:100)
==26486==    by 0x4025F0E8: plstrdup (plctrl.c:1722)
==26486==    by 0x40259775: plInitDispatchTable (plcore.c:1643)
==26486==    by 0x40258545: pllib_init (plcore.c:1092)
==26486==    by 0x40248DD0: plMergeOpts (plargs.c:703)
==26486==    by 0x8048E8C: main (x01c.c:101)
==26486==    by 0x4054214F: (within /lib/libc-2.2.5.so)
==26486==    by 0x8048DA1: plMergeOpts (in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/x01c)
==26486==
==26486== LEAK SUMMARY:
==26486==    definitely lost: 28 bytes in 2 blocks.
==26486==    possibly lost:   0 bytes in 0 blocks.
==26486==    still reachable: 6702 bytes in 225 blocks.
==26486==

Re: [Plplot-devel] tk driver

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

On Fri, 5 Jul 2002, Alan W. Irwin wrote:
> What is the difference between this driver, and say the tk one?  I might
> even be interested in doing the configuration changes that would be required
> to get this driver to work under Linux simply as an alternative testbed to
> its normal windows environment.  However, is there any other Linux
> motivation beyond that?  Would we be able to run a wider variety of demos or
> a different style of demos?  Also, on the other side of the coin would this
> driver require TEA to be working?

On Unix the tkwin driver is, indeed, very similar to the tk one (since it
is derived directly from it).  Main differences are:

(i) some bug fixes (particularly in initialisation, creation and
destruction under a variety of circumstances).
(ii) if you compile with 'USE_TCL_STUBS' and 'USE_TK_STUBS' defined, then
the shared library you produce can be loaded into _any_ tk interpreter
from 8.1 onwards (no recompilation necessary).
(iii) you can then use the extended 'Plplotwin' widget (in
bindings/tk-x-plat) which is quite nice.
(iv) in principle 'plserver' and executables like that can be replaced by
a simple script which is invoked by an ordinary 'wish' interpreter.  (i.e.
you don't need to compile a whole bunch of different executables for each
different platform).  However this bit would require a tcl script called
'plserver' which mimics plserver to be written.

Depending on your usage, none of the above may be compelling.  For people
on Mac OS, Mac OS X, Windows, of course there is no other 'tk' option, so
'tkwin' provides something very valuable.

The 'TEA' build process is not necessary for any of this.

cheers,

Vince.

Re: [Plplot-devel] tk driver

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

On Wed, 3 Jul 2002, Vince Darley wrote:

> I'd be interested if anyone has any success compiling pltcl with the
> 'tkwin' driver on Unix.  (makefile modifications will be needed, I assume).

What is the difference between this driver, and say the tk one?  I might
even be interested in doing the configuration changes that would be required
to get this driver to work under Linux simply as an alternative testbed to
its normal windows environment.  However, is there any other Linux
motivation beyond that?  Would we be able to run a wider variety of demos or
a different style of demos?  Also, on the other side of the coin would this
driver require TEA to be working?

Alan

Re: [Plplot-devel] version info, runalldemos.tcl, etc.

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

On Thu, 4 Jul 2002, Alan W. Irwin wrote:

> If example 8 (or any other multipage example) is the *first* button you
> press then the first page of example 8 is skipped and you start with the
> second page.  The remainder of the pages are accessible with CR.  If you
> press example 8 (or any other multi-page example) a *second* time the
> problem goes away, i.e., the first page is displayed properly and you have
> access to the rest with CR.  Just to be clear here, the exact same symptoms
> occur for tkdemos.tcl under plserver but not for tcldemos.tcl under pltcl.
> So the common factor seems to be plserver.

Ok, I definitely do not see that problem.  This is likely a bug in either
xwin.c or plframe.c (neither of which I am using with the new driver
setup), or plserver itself.

> > > One glitch in runAllDemos.tcl is the page button does
> > > not work.  Here is the stack trace delivered by plserver
> >
> > Does hitting 'return' work?
> 
> Yes.

Ok, I'll fix that soon.

Vince.

Re: [Plplot-devel] x09c.m problems

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

On Monday 01 July 2002 19:25, Alan W. Irwin wrote:
| During the course of running plplot-test.sh *from a completely fresh
| tree checked out from cvs* I found the following problem with the
| octave interface to plplot.
|
| error: plclabel_param' undefined near line 73 column 3
| error: evaluating index expression near line 73, column 3
| error: called from ix09c'
| error: near line 167 of file
| /home/software/plplot_cvs/HEAD/plplot_darley/bindings/octave/demos/x0
|9c.m'
|
| I cannot find plclabel_param defined anywhere in the octave tree.
|
| Joao, this problem has been introduced sometime since 5.1.0 when the
| plplot-test.sh script ran fine.  I suspect there is an additional
| file you need to commit to cvs to make sure plclabel_param is
| defined.

Thanks, I have now fixed the problem.

Joao