plplot-devel — Technical discussion about PLplot development

[Plplot-devel] automatic dependences do not work for RH 6.2 gcc

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

I went back to an old, "safe" system to see the current plplot build on it,
and here's what I got:

gazoo$ make
cd tmp; make default
gcc -c  -g        -O    -I. -I/home/mjl/gts.tst/include -MD -MF .d.pdfutils
-MP -c pdfutils.c -o pdfutils.o
gcc: cannot specify -o with -c or -S and multiple compilations
make[1]: *** [pdfutils.o] Error 1
make: *** [all] Error 2

gazoo$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

Starting to wonder if anything I do tonight's gonna work.

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

Re: [Plplot-devel] I can't install HEAD version

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

Sorry, the make install problem apparently is unrelated to tkwin.

Alan W. Irwin writes:
 > Maurice, I cannot reproduce the install bug you reported below.
 > ...
 > I assume you have looked at Makefile on your RH system?  Here, I have
 > 
 > SO              = .so
 > 
 > xwin_drv: shared/xwin$O $(TCLLIB_SO)
 > 
 > where
 > 
 > TCLLIB_SO        = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG)$(SO)
 > 
 > and eventually
 > 
 > TCLLIB_SO       = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG).so.$(SOVERSION)
 > 
 > where lib_sh_library.in is overriding the pkg_tcl.in definition.
 > 
 > If your RH7.3 Makefile is the same as mine, then from your results below,
 > the RH7.3 make command has ignored the second definition and used the first
 > definition instead with SO undefined.  That would be a really strange result
 > so I suspect your Makefile is somehow different from the above.
 > 
 > Wild guess to explain all this: on RH7.3 the linux system is somehow not
 > being recognized properly so lib_sh_linux.in is not being included as part
 > of the Makefile?

It's included.  For some reason the first definition is being used and not the
second.  I just commented out the first definition and reran 'make install'
and after that the install works fine.  Very odd.

ged$ make -v
GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.

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

Re: tkwin headers (was Re: [Plplot-devel] I can't install HEAD version)

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

Maurice LeBrun writes:
 > Maurice LeBrun writes:
 >  > I was also surprised to find the following dependencies with the tkwin stuff:
 >  > 
 >  > gcc -fPIC -c  -g        -O    -I. -I/home/mjl/gts/include -c plplotter.c -o
 >  > shared/plplotter.o
 >  > In file included from plplotter.c:276:
 >  > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory
 >  > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory
 >  > 
 >  > Ugh.  More internal TK headers that I need to remember to install I see.
 >  > (I already have several non-standard ones installed, sigh.)
 > 
 > After copying these two, now:
 > 
 > In file included from /home/mjl/gts.tst/include/tkInt.h:27,
 >                  from plplotter.c:276:
 > /home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory
 > make[1]: *** [shared/plplotter.o] Error 1
 > 
 > tkUnixPort.h?  This is getting pretty gross.  Does anyone have a complete list
 > of all the tk headers one needs to install?

Actually it's worse than just having to install a bunch of non-standard
headers.  How are we supposed to expect that there's a directory $prefix/unix
for holding tkUnixPort.h and the like?  This is not good.

I guess I'm back to omitting the tkwin driver and trying to fix the install
problem. 

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

Re: tkwin headers (was Re: [Plplot-devel] I can't install HEAD version)

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

Maurice LeBrun writes:
 > Maurice LeBrun writes:
 >  > I was also surprised to find the following dependencies with the tkwin stuff:
 >  > 
 >  > gcc -fPIC -c  -g        -O    -I. -I/home/mjl/gts/include -c plplotter.c -o
 >  > shared/plplotter.o
 >  > In file included from plplotter.c:276:
 >  > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory
 >  > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory
 >  > 
 >  > Ugh.  More internal TK headers that I need to remember to install I see.
 >  > (I already have several non-standard ones installed, sigh.)
 > 
 > After copying these two, now:
 > 
 > In file included from /home/mjl/gts.tst/include/tkInt.h:27,
 >                  from plplotter.c:276:
 > /home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory
 > make[1]: *** [shared/plplotter.o] Error 1
 > 
 > tkUnixPort.h?  This is getting pretty gross.  Does anyone have a complete list
 > of all the tk headers one needs to install?

BTW just for future reference, the culprit in plplotter.c responsible for all
this nonsense is:

PlPlotterKeyEH(ClientData clientData, register XEvent *eventPtr)  
{  
    ... 
    string = TkpGetString((TkWindow*)tkwin,eventPtr,&ds);  

where TkWindow is defined in tkInt.h.

So, is there really no workaround that goes through the public API?

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

tkwin headers (was Re: [Plplot-devel] I can't install HEAD version)

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

Maurice LeBrun writes:
 > I was also surprised to find the following dependencies with the tkwin stuff:
 > 
 > gcc -fPIC -c  -g        -O    -I. -I/home/mjl/gts/include -c plplotter.c -o
 > shared/plplotter.o
 > In file included from plplotter.c:276:
 > /home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory
 > /home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory
 > 
 > Ugh.  More internal TK headers that I need to remember to install I see.
 > (I already have several non-standard ones installed, sigh.)

After copying these two, now:

In file included from /home/mjl/gts.tst/include/tkInt.h:27,
                 from plplotter.c:276:
/home/mjl/gts.tst/include/tkPort.h:32:39: ../unix/tkUnixPort.h: No such file or directory
make[1]: *** [shared/plplotter.o] Error 1

tkUnixPort.h?  This is getting pretty gross.  Does anyone have a complete list
of all the tk headers one needs to install?

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

Re: [Plplot-devel] I can't install HEAD version

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

Alan W. Irwin writes:
 > Maurice, I cannot reproduce the install bug you reported below.
 > 
 > In fact, all your changes are working well here.
 > 
 > To be specific I did a vanilla checkout (with all your recent changes)
 > and
 > 
 > ./configure --prefix=/usr/local/plplot --enable-dyndrivers \
 > --enable-java --enable-gnome --enable-ntk --enable-tkwin

I suspect the problem's with the --enable-tkwin.  Try --enable-tk instead.

I was also surprised to find the following dependencies with the tkwin stuff:

gcc -fPIC -c  -g        -O    -I. -I/home/mjl/gts/include -c plplotter.c -o
shared/plplotter.o
In file included from plplotter.c:276:
/home/mjl/gts/include/tkInt.h:27:20: tkPort.h: No such file or directory
/home/mjl/gts/include/tkInt.h:878:24: tkIntDecls.h: No such file or directory

Ugh.  More internal TK headers that I need to remember to install I see.
(I already have several non-standard ones installed, sigh.)

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

Re: [Plplot-devel] I can't install HEAD version

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

Maurice, I cannot reproduce the install bug you reported below.

In fact, all your changes are working well here.

To be specific I did a vanilla checkout (with all your recent changes)
and

./configure --prefix=/usr/local/plplot --enable-dyndrivers \
--enable-java --enable-gnome --enable-ntk --enable-tkwin

make

no build problems except the usual python warnings.  Also, some quick checks
of -dev tk; -dev tkwin; -dev xwin; pltcl with tcldemos.tcl; plserver with
both tkdemos.tcl and runAllDemos.tcl; and wish with runAllDemos.tcl worked
fine. Also, I did some nm tests between libplplottcltk.so and
drivers/xwin_drv.so to make sure there were no cross-dependencies. Thus, all
your recent changes seem to be working fine.

I did

make install

and unlike the case for your RH7.3 system there were no problems at all.

I assume you have looked at Makefile on your RH system?  Here, I have

SO              = .so

xwin_drv: shared/xwin$O $(TCLLIB_SO)

where

TCLLIB_SO        = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG)$(SO)

and eventually

TCLLIB_SO       = $(PLLIB_PATH)$(TCLLIB_BASE)$(LIB_TAG).so.$(SOVERSION)

where lib_sh_library.in is overriding the pkg_tcl.in definition.

If your RH7.3 Makefile is the same as mine, then from your results below,
the RH7.3 make command has ignored the second definition and used the first
definition instead with SO undefined.  That would be a really strange result
so I suspect your Makefile is somehow different from the above.

Wild guess to explain all this: on RH7.3 the linux system is somehow not
being recognized properly so lib_sh_linux.in is not being included as part
of the Makefile?

Alan

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

Linux-powered astrophysics
__________________________

On Sun, 4 Aug 2002, Maurice LeBrun wrote:

> >From a vanilla checkout & configure, with dyndrivers, Linux RH7.3:
>
> $ make install
> make: *** No rule to make target `libplplottcltk', needed by `xwin_drv'.
> Stop.
>
> No idea.
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>
>
> -------------------------------------------------------
> 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
>

[Plplot-devel] xwin_common.c folded back into xwin.c

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

I finished the changes necessary to return the "external API" functions
previously moved to xwin_common.c back to xwin.c.  The driver escape function
is now used to access these, which is much cleaner from a linkage standpoint.

I was able to simplify the PLColor<->XColor interface by using a temporary
stream variable (tmpcolor), so all the extensions were trivial.

I did have to introduce a new call in plframe.c to pllib_initdev() (was
plGetDev) to load the device driver & set up the dispatch table before the
escape function can be called.

Anyhow it is a cleaner design now and everything seems to work fine, except
the install problem that was present before my commits.

Should be no problem to do this same procedure on the tkwin stuff.

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

Re: [Plplot-devel] Re: plplot interactive demo

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

Alan W. Irwin writes:
 > I look forward to seeing that demo, but currently the advanced user interface,
 > http://pcdb.ifjf.uib.no/index.html, is timing out.

Was working ok for me when I tried it just now.  

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

[Plplot-devel] I can't install HEAD version

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

From a vanilla checkout & configure, with dyndrivers, Linux RH7.3:

$ make install
make: *** No rule to make target `libplplottcltk', needed by `xwin_drv'.
Stop.

No idea.

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

Re: [Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

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

Let's get down to specifics.  Currently, all the tcl stuff is installed here

ls /usr/local/plplot/lib/plplot5.1.0/tcl
FileSelector.tcl  cmap0a.pal   cmap1d.pal      plcolor.tcl*    pltools.tcl
PLWin.itk         cmap1a.pal   help_gui.tcl    plconfig.tcl    plwidget.tcl
PLXWin.itk        cmap1a1.pal  help_keys.tcl   pldefaults.tcl  tclIndex
Pltkwin.tcl       cmap1b.pal   help_tcltk.tcl  plplot.tcl
about.tcl         cmap1c.pal   plclient.tcl    plserver.tcl

and the drivers are installed here

ls /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so
/usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so

where /usr/local/plplot is my prefix.

Are you suggesting copying bindings/tk-x-plat/pkgIndex.tcl to
$prefix/lib/plplot5.1.0/tcl and also putting a symbolic link from
that directory to the actual driver share object location (so it appears
the shared object is in the same directory as pkgIndex.tcl)?  I think you
also imply below that autopath would have to be changed to find
/usr/local/plplot/lib/plplot5.1.0/tcl, but I may be misunderstanding you.

What would be the exact wish recipe associated with what you would like me
to do?

Please give me the full wish cookbook.  Currently, my linking changes of
moving everything to tkwind_drv.so seems to have confused the ability of
wish to find the *.tcl files in /usr/local/plplot/lib/plplot5.1.0/tcl, and I
am hoping that problem will get straightened out by the changes you suggest
(perhaps the autopath change?) that are associated with the using the
pkgIndex.tcl file.

Incidentally, the library linking changes cause no problems with

/usr/local/plplot/bin/plserver
source tkdemos.tcl
1
2
3
...

but now if I try source runAllDemos.tcl instead, it (unlike tkdemos.tcl)
cannot find the x??.tcl examples in the current directory. I have no idea
why subtleties of linking are having this bad effect on the runAllDemos.tcl
case, but I hope you are able to change runAllDemos.tcl to look in the
current directory for x??.tcl so it won't be so sensitive to linking
changes.

Alan

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

Linux-powered astrophysics
__________________________

On Fri, 2 Aug 2002, Vince Darley wrote:

> [...] 'load' will search
> anything on your path, but, by and large all normal uses of 'load' specify
> a full path, so it's not so much of an issue.  for easiest use with
> tcl/tk, we will need to install something into the tcl/tk hierarchy so it
> is automatically picked up by them.  We need to put a directory (called,
> say, plplot5.1.0, but that doesn't matter too much) anywhere on Tcl's
> auto_path, and put the pkgIndex.tcl (from bindings/tk-x-plat) into that
> directory, together with appropriate information on where to find the .so
> it will be loading (currently that pkgIndex.tcl assumes that everything it
> is looking for will also be in that directory, since that is how things
> are installed for a normal Tcl extension).
>
> -- Vince
>
> <http://www.santafe.edu/~vince>
>
>
>
>

Re: [Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

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

>>>
The other immediate remaining issue is what symlinks should be set up to
$prefix/lib/plplot5.1.0/drivers/tkwind_drv.so in the installed case.  I
believe that question is related to Tcl/Tk packaging issues and what
directories are searched by the load command for installed dll's.
>>>

Retaining the tkwin_common.c split seems fine.  'load' will search
anything on your path, but, by and large all normal uses of 'load' specify
a full path, so it's not so much of an issue.  for easiest use with
tcl/tk, we will need to install something into the tcl/tk hierarchy so it
is automatically picked up by them.  We need to put a directory (called,
say, plplot5.1.0, but that doesn't matter too much) anywhere on Tcl's
auto_path, and put the pkgIndex.tcl (from bindings/tk-x-plat) into that
directory, together with appropriate information on where to find the .so
it will be loading (currently that pkgIndex.tcl assumes that everything it
is looking for will also be in that directory, since that is how things
are installed for a normal Tcl extension).

-- Vince

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

Re: [Plplot-devel] Re: plplot interactive demo

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

I look forward to seeing that demo, but currently the advanced user interface,
http://pcdb.ifjf.uib.no/index.html, is timing out.

Alan

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

Linux-powered astrophysics
__________________________

On Thu, 1 Aug 2002, Maurice LeBrun wrote:

> Thanks, I've forwarded this to the plplot development list.
>
> Pavel Filatov writes:
>  > Hello, Mr. LeBrun
>  > We are using PLplot library in Norwegian SeisSchool project
>  > http://pcg1.ifjf.uib.no for seismic traces visualization.
>  > You can click to the Advances User Interface, choose day and
>  > record. After this you can zoom, filter or envelop traces.
>  > It may be good example for your Online Demo
>  > http://plplot.sourceforge.net/demo/index.html
>  >
>  > With Best Regards,
>  > Pavel Filatov
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>
>
> -------------------------------------------------------
> 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
>

[Plplot-devel] Re: plplot interactive demo

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

Thanks, I've forwarded this to the plplot development list.

Pavel Filatov writes:
 > Hello, Mr. LeBrun
 > We are using PLplot library in Norwegian SeisSchool project
 > http://pcg1.ifjf.uib.no for seismic traces visualization. 
 > You can click to the Advances User Interface, choose day and
 > record. After this you can zoom, filter or envelop traces.
 > It may be good example for your Online Demo
 > http://plplot.sourceforge.net/demo/index.html
 > 
 > With Best Regards,
 > Pavel Filatov

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

[Plplot-devel] Problem with two plot windows on win32

[Olof S. <sve...@es...>]

Hi,

Jesse Stone send me this piece of code (I have just changed the streams
from 0 and 1 to 1 and 2 after a suggestion from Alan):

> #include <math.h>
> #include "plplot/plplot.h"
> 
> int main()
> {
>     int i;
>     float x[100], y[100];
> 
>     plsstrm(1);         //  Open first window and draw a sin curve
>     plsdev("win3");
>     plinit();
> 
>     plcol0(1);
>     plenv(0.0f, 10.0f, -1.2f, 1.2f, 0, 1);
>     plcol0(2);
>     pllab("(x)", "sin(x)", "Sin Function");
>     for (i = 0; i < 100; i++) {
>         x[i] = (float)i/10;
>         y[i] = (float)sin(x[i]);
>     }
>     plcol0(3);
>     plline(100, x, y);
> 
> 
>     plsstrm(2);         //  Open second window and draw a cos curve
>     plsdev("win3");
>     plinit();
> 
>     plcol0(1);
>     plenv(0.0f, 10.0f, -1.2f, 1.2f, 0, 1);
>     plcol0(2);
>     pllab("(x)", "cos(x)", "Cos Function");
>     for (i = 0; i < 100; i++) {
>         x[i] = (float)i/10;
>         y[i] = (float)cos(x[i]);
>     }
>     plcol0(3);
>     plline(100, x, y);
> 
> 
>     plend();
> 
>     return 0;
> }


He's trying to use the win3 driver but the problem is that the two plots
are mixed in the same window. Both Alan and I have tried the code using
the xwin and ntk drivers on Linux with the following results:

* xwin: Both graphs are displayed however only the last one is properly
refreshed. The first one is refreshed as soon as the last one is closed.

* ntk: Both graphs are properly displayed.

The win3 driver (win32) behaves like the xwin driver, with the addition
of mixing the two graphs in the last plot window when resizing or
forcing a refresh of the last window. 

I have tried to understand how the two plots can be mixed but failed so
far, so therefore I'd like to ask you if you can see where the problem
is occurring. The piece of code in the win3 driver that takes care of
replotting the graphs after a resize looks like this (slightly changed
with respect to the one in the CVS):

> LRESULT CALLBACK _export PlPlotWndProc (HWND hwnd,UINT message,	UINT wParam,LONG lParam)
> {
....
> 	PLStream *pls = (PLStream *)GetWindowLong(hwnd,GWL_USERDATA);
....	
> 	if (pls)
> 		dev = (WinDev *)pls->dev;
>	printf("DEBUG: in PlPlotWndProc... pls = %d\n",(int)pls);
....
> 	case WM_PAINT :
> 		if (dev) {
> 			if (dev->rePaint) {
> 			        HDC hdc_old = dev->hdc;
> 				HWND hwnd_old = dev->hwnd;
> 				dev->rePaint = 0;
> 				dev->rePaintBsy = 1;
> 				hcurSave = SetCursor(LoadCursor(NULL,IDC_WAIT));
> 				dev->hwnd = hwnd;
> 				dev->hdc = GetDC(hwnd);
> 				GetClientRect(hwnd,&rect);
> 				dev->xPhMax = rect.right;
> 				dev->yPhMax = rect.bottom;
> 				dev->xScale = rect.right / ((float)PIXELS_X);
> 				dev->yScale = rect.bottom / ((float)PIXELS_Y);
> 				plRemakePlot(pls);
> 				dev->rePaintBsy = 0;
> 				SetCursor(hcurSave);
> 				ReleaseDC(hwnd,dev->hdc);
>  	                        dev->hdc = hdc_old;
> 				dev->hwnd = hwnd_old;
> 				plD_state_win3(pls, PLSTATE_COLOR0); /* Set drawing color */
> 			}
> 			BeginPaint(hwnd,&ps);
> 			EndPaint(hwnd,&ps);
> 			return 0;
> 		}
> 		break;

I have checked that each window retrieves correctly the pointer to its
pls stream and hence the correct pls->dev context by printing out the
address of the pls pointer. When I resize the last window only one pls
pointer is printed out.

So, my question to you is therefore: How is it possible for the two
graphs to be mixed in the same window if plRemakePlot is called with
only one pls stream? Any suggestions are welcome!

Regards,

Olof

[Plplot-devel] Done for now with linking changes

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

The last change I did should allow you to dispense with LD_LIBRARY_PATH and
that completes my work on the linking model for the dynamic drivers case for
Linux (except if Vince wants me to reunite tkwin.c).  Maurice may want to
make some additional changes for the xwin case in the next few days.

Anyhow, please give the current CVS a thorough testing for the dynamic
drivers case on Linux both for the plplot/tmp location and the installed
location to make sure it works.  I think we should focus strictly on that
case for Linux at least until Joao and Geoffrey get back and have a chance
to evaluate it.

Once everybody is willing to live with the dyndrivers case linking solution
on Linux and after a current heavy time commitment on my part has eased a
bit (with luck in September), I will have time again to work on the case
when the dyndrivers are turned off.

After we are satisfied with all aspects of Linux linking for various
configuration options, I believe the next step after that should be libtool
to take advantage of the current well-behaved Linux linking hierarchy and go
cross-platform with it.  But I am unlikely to do that until Rafael can spend
some time on 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] tkwin.c is now split and I have also reorganized the linking on Linux

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

I have implemented this change in CVS by simply moving TKWIN_OBJ =
Plplotter_Init$O plplotter$O tkwin_common$O from libplplottcltkd to
drivers/tkwind_drv.so.

Maurice, could I have your comments on doing something similar for the xwin
driver?  In particular is it possible to move plframe$O from libplplottcltk
to xwind_drv.so without introducing a libplplottcltk dependency on
xwind_drv.so and thus introducing a cross-dependency between the two since
xwind_drv.so will always depend on libplplottcltk?  I resolved that
potential cross-dependency issue in the present case by also moving
Plplotter_Init$O to tkwind_drv.so because there was nothing else in
libplplottcltk that depended on Plplotter_Init$O.  However, I think in the
plframe$O case, there may be other objects within libplplottcltk that depend
upon it and which themselves cannot be moved to xwind_drv.so without
creating other cross-dependencies. If you cannot see any way to move
plframe$O and related objects to xwind_drv.so without creating
cross-dependencies, then I suggest you go ahead with the alternative
solution you have proposed of using escape functions.

The rest of this e-mail concerns some additional tkwin issues and is mostly
directed to Vince.

I have left tkwin_common.c separate for the moment because I am of two minds
about reuniting it with tkwin.c.  On the one hand, it is one extra file that
Vince has to keep track of.  On the other hand, my instinct is to keep this
file separate since conceptually it is different from the rest of xwin
(i.e.,both xwin.c and plplotter.c depend on the functions defined inside
it), and I prefer not to destroy the work I did to separate it. Admittedly,
that separation is not necessary at this time, but it might make future
changes easier to keep things split. I will leave this decision to your best
judgement, Vince, since you are the one most familiar with this area of
PLplot.

The other immediate remaining issue is what symlinks should be set up to
$prefix/lib/plplot5.1.0/drivers/tkwind_drv.so in the installed case.  I
believe that question is related to Tcl/Tk packaging issues and what
directories are searched by the load command for installed dll's.

So Vince, will you do the next steps in CVS to package everything for the
installed case?  Just tell me what directory and name (probably
libtkwin$(LIB_TAG).so) you need for the shared object that is loaded, and I
will symlink it on the Linux/Unix side to the appropriate tkwind_drv.so
install location.  Just to remind you what tcl stuff in installed, here is
the contents of $prefix/lib/plplot5.1.0/tcl currently installed on my
system.

ls /usr/local/plplot/lib/plplot5.1.0/tcl/
FileSelector.tcl  cmap0a.pal   cmap1d.pal      plcolor.tcl*    pltools.tcl
PLWin.itk         cmap1a.pal   help_gui.tcl    plconfig.tcl    plwidget.tcl
PLXWin.itk        cmap1a1.pal  help_keys.tcl   pldefaults.tcl  tclIndex
Pltkwin.tcl       cmap1b.pal   help_tcltk.tcl  plplot.tcl
about.tcl         cmap1c.pal   plclient.tcl    plserver.tcl

Also, you haven't yet answered my question about running tcldemos.tcl from
tclsh and tkdemos.tcl from wish.  I know we used to be able to do that on
the tea branch years ago, and I would like to see that neat functionality
available on cvs HEAD as well.

Alan

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

Linux-powered astrophysics
__________________________

On Tue, 30 Jul 2002, Vince Darley wrote:

> I think this is the right way to go --- makes sense both logically, and
> 'symbol-link-ably', at least to me.
>
> thanks for investigating and carrying out all this tricky work.
>
> -- Vince
>
> <http://www.santafe.edu/~vince>
>
>
> On Mon, 29 Jul 2002, Alan W. Irwin wrote:
>
> > On Mon, 29 Jul 2002, Vince Darley wrote:
> >
> > > >>
> > > A separate tkwin_common.c is necessary because both plplotter.c and (the
> > > new)
> > > tkwin.c depend on the functions defined in there.
> > > >>
> > >
> > > I have to say, I find this crazy!  It is not possible to use plplotter.c
> > > without tkwin.c and not possible to use tkwin.c without plplotter.c so,
> > > please, put them in the same .so!
> >
> > OK. A quick visual check of the source codes seemed to indicate moving
> > Plplotter_Init.o, plplotter.o tkwin_common.o from libplplottcltk to
> > drivers/tkwind_drv.so would work since nothing else in libplplottcltk seems
> > to depend on anything in those functions.
> >
> > IMPORTANT *all* these functions have to be moved since Plplotter_Init.o
> > depends on plplotter, and if you leave it behind you create a
> > cross-dependency and this affects the wish recipe, see below.
> >
> > Indeed when I tried that locally the -dev tkwin worked fine, i.e., gave its
> > usual message without any linking troubles at all.
> >
> > Same for plserver.  runAllDemos.tcl worked fine.
> >
> > But now the wish recipe we had before doesn't work...
> >
> > wish
> > % source pldefaults.tcl
> > % load libplplottcltkd.so Plplotter
> > couldn't find procedure Plplotter_Init
> >
> > Obviously it is looking for  Plplotter_Init inside
> > libplplottcltkd.so and cannot find it since that has been moved
> > to tkwind_drv.so.
> >
> > So now the new wish recipe from plplot/tmp should be
> >
> > source pldefaults.tcl
> > load drivers/tkwind_drv.so Plplotter
> > package provide Plplotter 5.1.0
> > source runAllDemos.tcl
> >
> > which works fine and makes sense under the hierarchical linking rules that
> > are now in place since tkwin depends on and links to libplplottcltk.
> > However, attempting to find tkwind_drv at its install location of
> > $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so will cause some trouble.  For
> > example, you will probably have to specify the complete path name to get it.
> > Ultimately, this could be solved with a symlink.
> >
> > Vince, if this is the way you want to go (reuniting tkwin_common with tkwin
> > and moving Plplotter_Init.o and plplotter.o from libplplottcltk to
> > drivers/tkwind_drv.so while accepting the wish recipe changes that result)
> > that is fine with me, but I need direct confirmation from you before I go to
> > the additional configuration work to make this the permanent solution.
> >
> > Alan
> >
> >
>
>

Re: [Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

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

I think this is the right way to go --- makes sense both logically, and
'symbol-link-ably', at least to me.

thanks for investigating and carrying out all this tricky work.

-- Vince

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


On Mon, 29 Jul 2002, Alan W. Irwin wrote:

> On Mon, 29 Jul 2002, Vince Darley wrote:
> 
> > >>
> > A separate tkwin_common.c is necessary because both plplotter.c and (the
> > new)
> > tkwin.c depend on the functions defined in there.
> > >>
> >
> > I have to say, I find this crazy!  It is not possible to use plplotter.c
> > without tkwin.c and not possible to use tkwin.c without plplotter.c so,
> > please, put them in the same .so!
> 
> OK. A quick visual check of the source codes seemed to indicate moving
> Plplotter_Init.o, plplotter.o tkwin_common.o from libplplottcltk to
> drivers/tkwind_drv.so would work since nothing else in libplplottcltk seems
> to depend on anything in those functions.
> 
> IMPORTANT *all* these functions have to be moved since Plplotter_Init.o
> depends on plplotter, and if you leave it behind you create a
> cross-dependency and this affects the wish recipe, see below.
> 
> Indeed when I tried that locally the -dev tkwin worked fine, i.e., gave its
> usual message without any linking troubles at all.
> 
> Same for plserver.  runAllDemos.tcl worked fine.
> 
> But now the wish recipe we had before doesn't work...
> 
> wish
> % source pldefaults.tcl
> % load libplplottcltkd.so Plplotter
> couldn't find procedure Plplotter_Init
> 
> Obviously it is looking for  Plplotter_Init inside
> libplplottcltkd.so and cannot find it since that has been moved
> to tkwind_drv.so.
> 
> So now the new wish recipe from plplot/tmp should be
> 
> source pldefaults.tcl
> load drivers/tkwind_drv.so Plplotter
> package provide Plplotter 5.1.0
> source runAllDemos.tcl
> 
> which works fine and makes sense under the hierarchical linking rules that
> are now in place since tkwin depends on and links to libplplottcltk.
> However, attempting to find tkwind_drv at its install location of
> $prefix/lib/plplot5.1.0/drivers/tkwind_drv.so will cause some trouble.  For
> example, you will probably have to specify the complete path name to get it.
> Ultimately, this could be solved with a symlink.
> 
> Vince, if this is the way you want to go (reuniting tkwin_common with tkwin
> and moving Plplotter_Init.o and plplotter.o from libplplottcltk to
> drivers/tkwind_drv.so while accepting the wish recipe changes that result)
> that is fine with me, but I need direct confirmation from you before I go to
> the additional configuration work to make this the permanent solution.
> 
> Alan
> 
> 

Re: [Plplot-devel] xwin.c is now split

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

Alan W. Irwin writes:
 > Maurice, the escape function implementations are beyond my expertise so I am
 > going to have to depend on you (and Vince) for those. Once they are done, I
 > think the configuration issues are trivial, but if you run into any trouble
 > with those I could certainly help at that point.

OK, no problem, I'll get to it in the next day or so.

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

Re: [Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

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

On Mon, 29 Jul 2002, Vince Darley wrote:

> >>
> A separate tkwin_common.c is necessary because both plplotter.c and (the
> new)
> tkwin.c depend on the functions defined in there.
> >>
>
> I have to say, I find this crazy!  It is not possible to use plplotter.c
> without tkwin.c and not possible to use tkwin.c without plplotter.c so,
> please, put them in the same .so!

OK. A quick visual check of the source codes seemed to indicate moving
Plplotter_Init.o, plplotter.o tkwin_common.o from libplplottcltk to
drivers/tkwind_drv.so would work since nothing else in libplplottcltk seems
to depend on anything in those functions.

IMPORTANT *all* these functions have to be moved since Plplotter_Init.o
depends on plplotter, and if you leave it behind you create a
cross-dependency and this affects the wish recipe, see below.

Indeed when I tried that locally the -dev tkwin worked fine, i.e., gave its
usual message without any linking troubles at all.

Same for plserver.  runAllDemos.tcl worked fine.

But now the wish recipe we had before doesn't work...

wish
% source pldefaults.tcl
% load libplplottcltkd.so Plplotter
couldn't find procedure Plplotter_Init

Obviously it is looking for  Plplotter_Init inside
libplplottcltkd.so and cannot find it since that has been moved
to tkwind_drv.so.

So now the new wish recipe from plplot/tmp should be

source pldefaults.tcl
load drivers/tkwind_drv.so Plplotter
package provide Plplotter 5.1.0
source runAllDemos.tcl

which works fine and makes sense under the hierarchical linking rules that
are now in place since tkwin depends on and links to libplplottcltk.
However, attempting to find tkwind_drv at its install location of
$prefix/lib/plplot5.1.0/drivers/tkwind_drv.so will cause some trouble.  For
example, you will probably have to specify the complete path name to get it.
Ultimately, this could be solved with a symlink.

Vince, if this is the way you want to go (reuniting tkwin_common with tkwin
and moving Plplotter_Init.o and plplotter.o from libplplottcltk to
drivers/tkwind_drv.so while accepting the wish recipe changes that result)
that is fine with me, but I need direct confirmation from you before I go to
the additional configuration work to make this the permanent solution.

Alan

Re: [Plplot-devel] xwin.c is now split

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

Maurice,

I just checked the current dependencies of xwin on libplplottcltk (the
reverse of the check that was done before) to make sure only those 3
functions were required.

for i in `nm -p drivers/xwind_drv.so | fgrep " U "| awk '{print $2}'`; do nm
-p libplplottcltkd.so | fgrep $i | fgrep " T "; done
00017abc T plX_setBGFG
00017bc4 T PLColor_to_XColor
0001747c T plD_open_xw

So indeed your change would mean xwin could link to libplplot rather than
libplplottcltk.  So it satisfies Joao's and your design concerns about what
the xwin driver links to and also slims down the libplplottcktk library
without causing any reverse linking or cross dependencies.  So it all sounds
good to me.

In the tkwin case, doing the escape function solution for
PLColor_to_TkColor, plD_open_tkwin, and pltkwin_setBGFG would allow putting
tkwin_common back together with tkwin and slimming the libplplottcktk
library some more without reverse linking or cross dependencies.  Of course
tkwin would still depend on other functions in libplplottcltk, (just like tk
now depends on libplplottcltk) but I believe that is fine from a design
perspective.  So that all sounds good to me as well.

Maurice, the escape function implementations are beyond my expertise so I am
going to have to depend on you (and Vince) for those. Once they are done, I
think the configuration issues are trivial, but if you run into any trouble
with those I could certainly help at that point.

Alan

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

Linux-powered astrophysics
__________________________

On Sun, 28 Jul 2002, Maurice LeBrun wrote:

> Maurice LeBrun writes:
>  > One possibility that might satisfy everyone, if it could work, is to use
>  > an escape function in the xwin driver for the missing commands.  Then there
>  > is separation without significant increase in work.  Has anyone looked into
>  > this approach?
>
> OK, I just did.  The three functions needed by plframe.c:
>
> | jcard:~/tmp/plplot/tmp > for i in `nm -p libpltcl.so | fgrep " U "| awk
> | '{print $2}'`; do nm -p drivers/xwin_drv.so | fgrep $i | fgrep " T ";
> | done
> | 00004900 T plX_setBGFG
> | 00005550 T PLColor_from_XColor
> | 00001d40 T plD_open_xw
>
> can without too much trouble be called via the escape function approach, thus
> removing them from consideration as external functions.  plX_setBGFG and
> plD_open_xw don't even need to pass any data, just the stream pointer and an
> operator index.  For PLColor_from_XColor, a pointer to a temporary structure
> would have to be passed.  In each case, we're talking about only one call from
> plframe.c, so the escape function approach seems reasonable to me.  Then the
> whole issue with where to put these functions is avoided, and the xwin related
> logic remains in xwin.c, very simple and effective.  So I'd like to go back
> to the way it was but with these functions turned into escape functions.
>
> Presumably this can be done with the tkwin_common.c stuff too.
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>
>
> -------------------------------------------------------
> 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] tkwin.c is now split and I have also reorganized the linking on Linux

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

>>
A separate tkwin_common.c is necessary because both plplotter.c and (the
new)
tkwin.c depend on the functions defined in there.
>>

I have to say, I find this crazy!  It is not possible to use plplotter.c
without tkwin.c and not possible to use tkwin.c without plplotter.c so,
please, put them in the same .so!

-- Vince

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


On Sun, 28 Jul 2002, Alan W. Irwin wrote:

> Joao: please read all of this before you comment....;-)
> 
> tkwin.c is now split into tkwin_common.c and tkwin.c following pretty
> much what I did in the xwin_common.c and xwin.c case.
> 
> In direct analogy with the xwin_common case there was a plplot_tkwin_ccmap
> definition that I had to deal with.  I probably did it in a clumsy way so
> if anybody can come up with a better solution, please commit it (and
> same remark about plplot_ccmap in the xwin_common case).  There may also
> be some compiler warning issues, but I leave that to the C experts here
> to fix up.
> 
> A separate tkwin_common.c is necessary because both plplotter.c and (the new)
> tkwin.c depend on the functions defined in there.
> 
> Vince, I think the only practical difference this will make to you is you
> have to deal with tkwin_common.c now.
> 
> Now on to the Linux library reorganization:
> 
> (1) It works! (which is quite important to me).  I have not done my complete
> tests, but I did try the tk device from various front ends, and also pltcl,
> plserver, and wish (all from plplot/tmp with LD_LIBRARY set to ./).
> 
> The wish recipe is now changed (as noted also in examples/tk/README.tkdemos.)
> 
> wish
> source pldefaults.tcl
> load libplplottcltkd.so Plplotter
> package provide Plplotter 5.1.0
> source runAllDemos.tcl
> 
> libplplotd will no longer work in that second line because of the
> reorganized linking (see below), but this way is more logical in any case.
> 
> Vince, years ago when we first played with this I recall there was a
> way to run tkdemos.tcl under wish and tcldemos.tcl under tclsh.  I cannot
> do that at the moment, but are we close to that status again?
> 
> (2) Joao: your last message seemed rather irritated by my changes, but
> please think of this as one step in a process rather than the final perfect
> solution.  I have carefully read your e-mails on this subject, and I believe
> others here have as well (and I also hope Geoffrey makes a special effort to
> do so when he gets back).  If I read you correctly, you want to split
> libraries up some more beyond what I have done already.  I am not against
> that at all.  In fact, I would love to see tclAPI.c get more and more lonely
> in its library to make it as parallel as possible with the nice clean
> interface we have for python. So I am basically on your side.  But I was
> concerned your arguments did not take library linking constraints into
> account which are absolutely dictated by the source file contents. However,
> if you can find a way to do what you want without introducing reverse
> linking (see below), I would have no objection at all.
> 
> (3) IMPORTANT Shared library linking constraints:
> 
> Here is the deal as I understand it.  Suppose in Linux you have liba
> depending on libx and libx depending on liby.  What I mean by "depending on"
> here is that liba requires some functions that are defined in libx and libx
> requires some functions that are defined in liby.  Special note: these
> dependencies are completely dictated by the content of the C code, i.e., the
> actual objects that get put into each library.  Also, it is important to
> have the dependencies one way only to avoid cross-dependency issues (and of
> course that was the motivation for splitting xwin and tkwin.)
> 
> In Linux you can be completely sloppy about the way you link liba, libx, and
> liby together and also the way you link your applications.  For example, you
> can link liba to liby and liby to libx and your applications to liba and it
> or any other permutation will work on Linux!  But it won't work
> cross-platform because some platforms demand only forward linking, e.g.,
> reverse-linking (against the dependency) liby to libx won't work on some
> platforms.
> 
> For cross-platform use the safe way to do things for the above dependency
> heirarchy is to link to the highest members in the hierarchy that a given
> application or library is dependent on.  That is, link your applications
> only to liba, liba only to libx, and libx only to liby. That will continue
> to work fine on Linux.  But for cross-platform use one more step is
> required; you must use libtool to translate automatically for each platform
> this hiearchy of dependencies you have specified into something that works
> fine for each platform.  libtool handles all the details of taking account
> of the linker limitations of every platform.  But my understanding from
> reading the libtool documentation is if you build in reverse linking or
> cross linking, you are hosed!
> 
> The current status is the linking changes I made today are consistent with
> the hierarchical rule above and the known linking dependencies that we have
> as dictated by the current contents of the libraries.  libplplottcktk
> depends on and links to libplplot and libtclmatrix; all dynamic drivers
> other than xwin, tkwin, and tk depend on and link to libplplot; the xwin,
> tkwin, and tk drivers depend both on libplplottcktk and libplplot, but only
> link to libplplottcktk (the higher member in the hierarchy); and libplplot
> and libtclmatrix depend on no other libraries in plplot so link to none of
> them. No library depends on a dynamic driver. Most applications (e.g., x01c,
> plrender) depend only on libplplot so that is all they link to. pltcl and
> plserver depend both on libplplottcktk and libplplot, but only need to link
> to the higher member, libplplottcktk.
> 
> Joao, if you decide to split or reorganize the libraries (including dynamic
> drivers) some more, please be really careful of the dependencies (dictated
> by exactly which functions you put into the various libraries and dynamic
> drivers) so that your changes do not introduce cross-linking, reverse
> linking, or linking of libraries to dynamic drivers again.  Such a mess
> would probably work on Linux, but would destroy the potential we have at the
> moment for nice cross-platform handling of our linking with libtool.
> 
> 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
> __________________________
> 
> 
> 
> -------------------------------------------------------
> 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] xwin.c is now split

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

>>>
Come on! the tk driver needs the plframe, that needs the xwin driver! 

And yes, I think that plframe.o should be part of the driver, and as 
such linked with tk.o to make tk_drv. But the plframe only makes sense 
with tclAPI, so should we link them all? No, if I configure with 
--enable-tcl --disable-tk, than tclAPI.o will be built, plframe.o will 
not, and I can use other driver then the tk_drv one.
>>>

To throw in my 2 cents... I agree very much with the above.  The plframe
and tk.c are both parts of the tk driver.  The fact one may be able to
link one or other without the other is beside the point, and this means
that the stuff which was in xwin.c is required by the tk driver (again
whether one can link or not without it). The various
'plwidget.tcl' and related files are also effectively part of the tk
driver (even though they aren't compiled, of cours).

However, the 'pure-tcl' bindings (tclAPI.c) can be used completely
independently (and in fact much of that code isn't even used by the tk
driver --- one might wish to split that out into a common 'Plbasic_Init'
used by Tcl AND tk bindings, and the 'Pltcl_Init' stuff whicvh is only
used by the Tcl bindings (not Tk).

cheers,

-- Vince

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

Re: [Plplot-devel] tkwin.c is now split and I have also reorganized the linking on Linux

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

I also apologize if I moved too fast.  But I also am time constrained, so i=
t
was a question of do it now or forget it.  Also, I thought in this case tha=
t
the best way was to demonstrate in CVS a working solution to the problem of
making the tk, xwin, and tkwin drivers dynamic. This solution does not
preclude more changes so long as we avoid reverse-linking and the like.

Glad for that smiley below....

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
__________________________

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

> On Monday 29 July 2002 01:37, Alan W. Irwin wrote:
> |  Joao: please read all of this before you comment....;-)
> ...
> |
> |  (2) Joao: your last message seemed rather irritated by my changes,
>
> Perhaps. I apologize. I'm needing vacations, which will arrive in a
> couple of days, after the end of semester paper-work is finished.
>
> I will see all you within a month. Till then, keep doing a good work
> Alan (but wait for a consensum, or at least for a resignation :-)
>
> Joao
>
>
>
>
> -------------------------------------------------------
> 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] tkwin.c is now split and I have also reorganized the linking on Linux

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

On Monday 29 July 2002 01:37, Alan W. Irwin wrote:
|  Joao: please read all of this before you comment....;-)
=2E..
|
|  (2) Joao: your last message seemed rather irritated by my changes,

Perhaps. I apologize. I'm needing vacations, which will arrive in a=20
couple of days, after the end of semester paper-work is finished.

I will see all you within a month. Till then, keep doing a good work=20
Alan (but wait for a consensum, or at least for a resignation :-)

Joao