plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Debian gets 5.1.0, CVS updated

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

On Tue, 3 Sep 2002, Alan W. Irwin wrote:

> BTW, some of my current linking changes have messed up relocatibility of the
> install location (required for both rpm and deb packaging).  I am working on
> fixing that at the moment, but once that is done, it would be most
> interesting to see if debs could be built from CVS HEAD.

I believe I now have this relocatibility issue completely solved.  For
example, the remaining itcl issue that is blocking me from building RH 7.3
rpm's from current CVS does not seem to be related to relocatibility.  To
test this, however, I would like to try to build the debs from CVS HEAD.

David, can you make the debian subdirectory available to CVS HEAD so I can
try the build or is there some reason why the debian subdirectory should
remain isolated in its own CVS branch?

Alan

Re: [Plplot-devel] python works fine on RH 7.3

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

P.S. My version of swig is 1.3.11-1.  The latest swig available at
http://prdownloads.sf.net/swig is swig-1.3.14.tar.gz.  I presume that is the
one you have been trying, but you might want to back off to
swig-1.3.11.tar.gz from the same site to see if you replicate my swig
generated results in that case.  Note, any version less than 1.3.11 will
probably not work.

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 Wed, 4 Sep 2002, Alan W. Irwin wrote:

> Maurice, I just built the plplot (1.5) python interface on RH 7.3 without
> any problems For example, I can run pythondemos.py in plplot/tmp without any
> problems.
>
> One potentially significant difference from your effort is I
> used the attached python interface files that I generated with swig
> on my Debian system.  Could you please do the following?
>
> (1) See if the attached files work for you.  They of course should be placed
> in bindings/python with the exact names I have given them.  The Makefile and
> the symlinks set up in tmp by configure should take care of the rest.
>
> (2) If you also obtain success with those interface files, then please
> compare them with what is generated by the latest-generation swig you
> installed on your RH7.3 system, and please let me know what differences
> there are.
[...]

[Plplot-devel] python works fine on RH 7.3

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

Maurice, I just built the plplot (1.5) python interface on RH 7.3 without
any problems For example, I can run pythondemos.py in plplot/tmp without any
problems.

One potentially significant difference from your effort is I
used the attached python interface files that I generated with swig
on my Debian system.  Could you please do the following?

(1) See if the attached files work for you.  They of course should be placed
in bindings/python with the exact names I have given them.  The Makefile and
the symlinks set up in tmp by configure should take care of the rest.

(2) If you also obtain success with those interface files, then please
compare them with what is generated by the latest-generation swig you
installed on your RH7.3 system, and please let me know what differences
there are.

Note, most users will have access to the attached files since I will be
including them in the release tarball for the next release in
bindings/python.  It is only cvs users that have to build them for
themselves with swig (or use the attached versions until the next tweak
of the python interface).

I also found there was an itcl installation problem on RH7.3.  Once we
are on the same page with respect to the python interface, could you look
into that?  The error messages were:

no files matched glob patterns "*.tcl *.itcl *.itk *.ith *.itm"
    while executing
"glob *.tcl *.itcl *.itk *.ith *.itm"
    ("eval" body line 1)
    invoked from within
"eval glob $args"
    (procedure "auto_mkindex" line 24)
    invoked from within
"auto_mkindex . *.tcl *.itcl *.itk *.ith *.itm"
    invoked from within
"if {[catch {package require Itcl}]} {

# Error including Itcl -- only include tcl files
    auto_mkindex . *.tcl

I currently have no idea where this is coming from and would be most
interested in whether the same installation error happens on your RH7.3
machine.

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] Debian gets 5.1.0, CVS updated

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

Thanks, Dave, for working on this.

I am fairly ignorant of the mechanics of working with branches, but I
presume that the DEBIAN tag I see on your CVS changes in the debian
subdirectory refers to changes on the DEBIAN branch that Rafael set up
some time ago.  Is it also true that the rest of the DEBIAN branch is
indistinguishable from 5.1.0 except for the minor patch below?

If so, I would appreciate you copying the debian subdirectory to CVS HEAD
(including the minor patch which you could keep as a special file in the
debian subdirectory.) I am assuming here that all changes would be confined
to the debian subdirectory.  BTW, this is exactly how the KDE debs are
maintained.  KDE CVS HEAD includes a debian subdirectory which is updated
from time to time by the Debian package maintainer so that anybody can build
their own KDE debs directly from KDE CVS HEAD.

Of course, the big advantage of making Debian buildable from CVS HEAD is you
don't perpetually have to play catch-up with all the rest of the CVS HEAD
changes that currently have to be migrated to the DEBIAN branch.
Furthermore, if the debian subdirectory exists for CVS HEAD, I could always
test on my Debian system that the debs remain at least buildable with all
our CVS HEAD changes.

If you follow up on my request, I suspect you will not need the second part
of the patch for current CVS HEAD.

BTW, some of my current linking changes have messed up relocatibility of the
install location (required for both rpm and deb packaging).  I am working on
fixing that at the moment, but once that is done, it would be most
interesting to see if debs could be built from CVS HEAD.

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, 3 Sep 2002, David Schleef wrote:

>
> I recently uploaded plplot-5.1.0 to Debian/unstable, since Rafael
> was on vacation.  And more recently, I merged all the past
> uploads into the debian directory on the DEBIAN branch in CVS.
> There's a bit of patching left in the Debian packaging, attached
> below.  The first looks like a hack, the second is a python-2.1
> fix.  (I don't remember if I wrote them or not. =) )
>
>
>
> dave...
>
>
> Index: cf/configure.in
> ===================================================================
> RCS file: /cvsroot/plplot/plplot/cf/configure.in,v
> retrieving revision 1.142
> diff -u -r1.142 configure.in
> --- cf/configure.in	28 Jul 2002 22:41:15 -0000	1.142
> +++ cf/configure.in	4 Sep 2002 02:25:53 -0000
> @@ -570,7 +570,8 @@
>  # around this potential problem by just defining caddr_t to 'char *' on all
>  # systems (unless it is set already), whether it will be needed or not.
>
> -AC_CHECK_TYPE(caddr_t, char *)
> +# This check is busted.  Since linux has caddr_t, just turn off the check.
> +#AC_CHECK_TYPE(caddr_t, char *)
>
>  # ----------------------------------------------------------------------------
>  # If you don't know what this is for you shouldn't be using it.
> Index: cf/sysloc.in
> ===================================================================
> RCS file: /cvsroot/plplot/plplot/cf/sysloc.in,v
> retrieving revision 1.108
> diff -u -r1.108 sysloc.in
> --- cf/sysloc.in	20 Aug 2002 10:57:06 -0000	1.108
> +++ cf/sysloc.in	4 Sep 2002 02:25:54 -0000
> @@ -962,6 +962,10 @@
>  if test "$with_dbmalloc" = "yes"; then
>      if test -z "$DBMALLOCINCDIR"; then
>  	incdirs="\
> +	$prefix/include/python2.1 \
> +	/usr/include/python2.1 \
> +	$prefix/include/python2.1/Numeric \
> +	/usr/include/python2.1/Numeric \
>  	$prefix/include \
>  	$HOME/local/include \
>  	$HOME/local/dbmalloc/include \
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] Debian gets 5.1.0, CVS updated

[David S. <ds...@sc...>]

I recently uploaded plplot-5.1.0 to Debian/unstable, since Rafael
was on vacation.  And more recently, I merged all the past
uploads into the debian directory on the DEBIAN branch in CVS.
There's a bit of patching left in the Debian packaging, attached
below.  The first looks like a hack, the second is a python-2.1
fix.  (I don't remember if I wrote them or not. =) )



dave...


Index: cf/configure.in
===================================================================
RCS file: /cvsroot/plplot/plplot/cf/configure.in,v
retrieving revision 1.142
diff -u -r1.142 configure.in
--- cf/configure.in	28 Jul 2002 22:41:15 -0000	1.142
+++ cf/configure.in	4 Sep 2002 02:25:53 -0000
@@ -570,7 +570,8 @@
 # around this potential problem by just defining caddr_t to 'char *' on all
 # systems (unless it is set already), whether it will be needed or not.
 
-AC_CHECK_TYPE(caddr_t, char *)
+# This check is busted.  Since linux has caddr_t, just turn off the check.
+#AC_CHECK_TYPE(caddr_t, char *)
 
 # ----------------------------------------------------------------------------
 # If you don't know what this is for you shouldn't be using it.
Index: cf/sysloc.in
===================================================================
RCS file: /cvsroot/plplot/plplot/cf/sysloc.in,v
retrieving revision 1.108
diff -u -r1.108 sysloc.in
--- cf/sysloc.in	20 Aug 2002 10:57:06 -0000	1.108
+++ cf/sysloc.in	4 Sep 2002 02:25:54 -0000
@@ -962,6 +962,10 @@
 if test "$with_dbmalloc" = "yes"; then
     if test -z "$DBMALLOCINCDIR"; then
 	incdirs="\
+	$prefix/include/python2.1 \
+	/usr/include/python2.1 \
+	$prefix/include/python2.1/Numeric \
+	/usr/include/python2.1/Numeric \
 	$prefix/include \
 	$HOME/local/include \
 	$HOME/local/dbmalloc/include \

RE: [Plplot-devel] decoupling drivers from libplplot

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

On Tue, 3 Sep 2002, Maurice LeBrun wrote:

> Geoffrey Furnish writes:
>  > The last time I used the python binding in PLplot, I built a complete
>  > python from scratch, and installed the numeric module by hand, and did
>  > everything static.  So, I know how to do it if I go that way.  But I
>  > am under the impression that other PLplot developers aren't going that
>  > route.  What is the state of things in the Python universe these days?
>  > For example, is there an rpm for RedHat 7.3 that I could install which
>  > adds the numeric stuff to a stock Python install?
>
> I didn't find one for python2.2 when I went looking.

For python2.2 try http://prdownloads.sf.net/numpy/Numeric-22.0-1.i386.rpm.

Alan

Re: [Plplot-devel] decoupling drivers from libplplot

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

On Tue, 3 Sep 2002, Geoffrey Furnish wrote:

> The linkage thing is just one piece of the pie.

OK.  Thanks for the explanation of the additional benefits of this approach.

Alan

RE: [Plplot-devel] decoupling drivers from libplplot

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

Geoffrey Furnish writes:
 > The last time I used the python binding in PLplot, I built a complete
 > python from scratch, and installed the numeric module by hand, and did
 > everything static.  So, I know how to do it if I go that way.  But I
 > am under the impression that other PLplot developers aren't going that
 > route.  What is the state of things in the Python universe these days?
 > For example, is there an rpm for RedHat 7.3 that I could install which
 > adds the numeric stuff to a stock Python install?

I didn't find one for python2.2 when I went looking.  But it builds & installs
just fine from the tarball.  As for python1.5, python-numpy-15.3-1.i386.rpm
does the job.

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

Re: [Plplot-devel] python status under RH7.3 (was decoupling drivers from libplplot)

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

Alan W. Irwin writes:
 > That should bring you up to speed to where Maurice was. I am reposting what
 > I said below (which summarizes the RH 7.3 python status) to the list in
 > answer to his last python question.  I don't believe Maurice followed up on my
 > suggested solution so I don't know whether dropping "module" from the shared
 > object name will work or not, but I am guessing it will.

I've been meaning to write about this once I got to dig a little further but
never got around to it.  Short story: still doesn't work.  I'm going to look
into it some more and will write back if anything changes.

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

Re: [Plplot-devel] decoupling drivers from libplplot

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

Alan W. Irwin writes:
 > On Mon, 2 Sep 2002, Geoffrey Furnish wrote:
 > 
 > > Okay, well, I bit the bullet, and implemented a large part of the env
 > > handle object thing that I've discussed recently, and previously.
 > >
 > > So I went to test it, and as the first step, I tried to run the ps
 > > driver inside a java example (this is with dyn drivers), but without
 > > first changing ps.c to eliminate the direct linkage to plPhyRot.
 > >
 > > Curiously, it ran without difficulty.
 > 
 > I just tried replacing
 > 
 > gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o -L. -lplplotd
 > 
 > with
 > 
 > gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o
 > 
 > and it didn't generate any errors at all from either python or java.  But
 > then I recalled the dlopen code tries both the plplot/tmp/drivers location
 > and installed location for something valid.  So I removed my installed
 > version (you should do this as well), and then both python and java fail to
 > work with the second form, but work fine with the first form.

Oh, duh, I shouldda thot o' that.   Okay, I'll try again tonight when
I get back to the machine with that dev strain on it.

 > > Just to confirm:  Alan, you're using a JDK less than 1.4.0, and if you
 > > drop the -lplplot when linking psd_drv.so, then you can't run the ps
 > > driver inside a java example, right?
 > 
 > Yep, I was using jdk1.2.2 with the above example.  But I think that might be
 > a red herring.  Try again with the above shortened link line with no
 > installed version of plplot, and I suspect you will also see errors with
 > both java and python.

Yeah, probably.  And if so, that will provide the test environment I
need for making sure the plenv thing is really working right.

 > BTW, I thought your "possible security reasons" explanation for why both
 > java and python were forcing -L. -lplplot[d] on the gcc line above was a
 > reasonable explanation.  Which begs the question should we be doing extra
 > coding ourselves simply to avoid putting -L. -lplplot[d] on the gcc line? By
 > reading through the posts in historical order, you may have gotten the
 > impression this was still unsolved, but the configuration has long been
 > changed so that -L. -lplplot[d] or -L. -lplplottcltk[d] is done
 > appropriately for all drivers.

Well, okay, there's a lot of history here, and I am coming back into
it after an absence, so perhaps I'm detuned.

I had dyndrivers working long before your recent flurry, and the way I
did it before, was to link them to -lplplot.  Now, there were some
iterations of that as well.  There were times when cvs head didn't
link the drivers to libplplot, and I didn't notice it to be a problem
because I didn't test with the drivers that actually called functions
in libplplot.  And then sometimes also I was running in x01c and
friends, and failed to notice that running dyndrivers inside x01.java
was different than running them in x01c.  So, the code fluctuated a
few times, but in the end (before your recent activity), the drivers
were linked to libplplot.  So, yes, I knew that that was a "solution",
of sorts.

And sure, you could say, if there is a solution of sorts, why mess
with any more swdev intensive approach?

My feeling is that the JNI env handle model, is actually really a good
idea.  Not just a dumb hack.  

For one thing, it makes the drivers more transportable.  By not being
specifically linked to libplplot, but just being truly dynloadable
modules, it means people will be able to cart them around without
worrying specifically which version of the library they were compiled
for.  Do I expect people to be trafficking in illegally imported
plplot dynamic drivers?  Of course not :-).  But the point is, it is
one more type of coupling removed, and intrinsically valuable from
that standpoint.

Another aspect of it is that it formalizes the notion of support
services that PLplot provides to drivers.  There are several functions
already, but it looks like kind of a strange collection of API's.  By
calling attention to it in the code, and collecting the provisioning
of these services into one place, it should make it easier to reason
about how to better organize what's there, as well as to flesh it out.

I think there's stuff, especially related to coordinate
transformations, that could probably be usefully pulled out from the
interactive drivers, and moved into an area where they can be more
easily shared by all the drivers.

Noel Gorelick once ruefully noted on the list, that way too much
effort had been dumped into the plframe interface, and too little
effort dumped into constructing reusable services for implementing
widgets.  Although I didn't share his antipathy for plframe, I
certainly do share his view of vision of infrastructure development to
promote the construction of disparate intractive widgets for PLplot to
play in multiple toolkit environments.

I think the move to the concept of a handle for reaching a family of
driver support functions, can be a useful approach to this.  It
certainly works handsomely well in the Java Native Interface world.

The linkage thing is just one piece of the pie.

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] decoupling drivers from libplplot

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

On Mon, 2 Sep 2002, Geoffrey Furnish wrote:

> Okay, well, I bit the bullet, and implemented a large part of the env
> handle object thing that I've discussed recently, and previously.
>
> So I went to test it, and as the first step, I tried to run the ps
> driver inside a java example (this is with dyn drivers), but without
> first changing ps.c to eliminate the direct linkage to plPhyRot.
>
> Curiously, it ran without difficulty.

I just tried replacing

gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o -L. -lplplotd

with

gcc -shared -fPIC -o drivers/psd_drv.so shared/ps.o shared/pstex.o

and it didn't generate any errors at all from either python or java.  But
then I recalled the dlopen code tries both the plplot/tmp/drivers location
and installed location for something valid.  So I removed my installed
version (you should do this as well), and then both python and java fail to
work with the second form, but work fine with the first form.

>
> Just to confirm:  Alan, you're using a JDK less than 1.4.0, and if you
> drop the -lplplot when linking psd_drv.so, then you can't run the ps
> driver inside a java example, right?

Yep, I was using jdk1.2.2 with the above example.  But I think that might be
a red herring.  Try again with the above shortened link line with no
installed version of plplot, and I suspect you will also see errors with
both java and python.

BTW, I thought your "possible security reasons" explanation for why both
java and python were forcing -L. -lplplot[d] on the gcc line above was a
reasonable explanation.  Which begs the question should we be doing extra
coding ourselves simply to avoid putting -L. -lplplot[d] on the gcc line? By
reading through the posts in historical order, you may have gotten the
impression this was still unsolved, but the configuration has long been
changed so that -L. -lplplot[d] or -L. -lplplottcltk[d] is done
appropriately for all drivers.

Alan

[Plplot-devel] python status under RH7.3 (was decoupling drivers from libplplot)

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

In answer to Geoffrey's implied question about RH7.3 python status:

Different Numeric rpm's are required depending on whether you are using
python1.5 or python2.1 or 2.2.  In the first case, use
http://prdownloads.sf.net/numpy/python-numpy-15.3-1.i386.rpm.  In the latter
case for Debian with python2.1, I use the Debian package that goes with
python2.1 which is Numeric version 21.0.  Because the Numeric version
numbers seem to be the python version multiplied by 10, then do the
appropriate multiplication to find the correct rpm for you in
http://prdownloads.sf.net/numpy/.  There are several 21.0 and 22.0 rpm's
there.

That should bring you up to speed to where Maurice was. I am reposting what
I said below (which summarizes the RH 7.3 python status) to the list in
answer to his last python question.  I don't believe Maurice followed up on my
suggested solution so I don't know whether dropping "module" from the shared
object name will work or not, but I am guessing it will.

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
__________________________

---------- Forwarded message ----------
Date: Fri, 23 Aug 2002 09:51:03 -0700 (PDT)
From: Alan W. Irwin <ir...@uv...>
Cc: PLplot development list <Plp...@li...>
Subject: Re: [Plplot-devel] problems with python bindings under RH7.3

On Thu, 22 Aug 2002, Maurice LeBrun wrote:

> Good news and bad news.  The bad news is, it still doesn't work.  The good
> news is that it's the exact same error message I got with python2.2, so maybe
> if a solution is found it will apply to both.  Here it is:
>
> trinity$ ./pythondemos.py
> Traceback (innermost last):
>   File "./pythondemos.py", line 15, in ?
>     from plplot import *
>   File "/home/mjl/dev/plplot/plpy/tmp/plplot.py", line 20, in ?
>     from plplotc import *
> ImportError: dynamic module does not define init function (initplplotc)


That reminds me of an error that Olof was getting on windows.  The solution
was to drop "module" from the name of the created shared object (i.e
plplotc.so rather than plplotcmodule.so).  I wondered at the time whether
the windows version of python was no longer supporting those legacy-style
'module.so names, but perhaps it is Debian that is the odd man out by still
allowing them.  Note Gary has always used *.so names with "module"
dropped, and that may be one key to his success on RedHat (and windows and
mac os x).

To try the shortened names, in plplot/tmp remove plplotcmodule.so and
plplot_widgetmodule.so and change the lines in the (configure-generated)
setup.py from

module1 = Extension( "plplotcmodule",  ==>
module1 = Extension( "plplotc",

and

module2 = Extension( "plplot_widgetmodule",  ==>
module2 = Extension( "plplot_widget",

Then execute make to generate plplotc.so and plplot_widget.so, etc. Let us
know if that works.  If it does, then go ahead and make the permanent
setup.py.in changes and the modest configuration changes to do with the
changed plplot*.so names.

If that doesn't work for you, then my plan is to copy my test environment to
a RH 7.3 box I have access to and then figure out what is best to do for
that environment. However, I have no time to pursue that now.  It would be at
the top of my PLplot agenda once I have a chance to work on PLplot again in
September or October, but I am hoping somebody else will figure it out before
then.

Alan



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Plplot-devel mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-devel

RE: [Plplot-devel] decoupling drivers from libplplot

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

Geoffrey Furnish writes:
 > Alan (or anyone), exactly how should I configure and run to exercise
 > the python binding with dyndrivers?

I configured with --enable-python, but it couldn't find arrayobject.h,
so it disabled Python support.  

The last time I used the python binding in PLplot, I built a complete
python from scratch, and installed the numeric module by hand, and did
everything static.  So, I know how to do it if I go that way.  But I
am under the impression that other PLplot developers aren't going that
route.  What is the state of things in the Python universe these days?
For example, is there an rpm for RedHat 7.3 that I could install which
adds the numeric stuff to a stock Python install?

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] decoupling drivers from libplplot

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

Okay, well, I bit the bullet, and implemented a large part of the env
handle object thing that I've discussed recently, and previously.

So I went to test it, and as the first step, I tried to run the ps
driver inside a java example (this is with dyn drivers), but without
first changing ps.c to eliminate the direct linkage to plPhyRot.

Curiously, it ran without difficulty.

I am using JDK 1.4.0_01 on this system.  Evidently, they changed the
RTLD thing on this JDK.  That's really funny, and maybe corroborates
Alan's "they forgot it" theory.  I dunno, anyway, it behaves
differently than I remember.

Just to confirm:  Alan, you're using a JDK less than 1.4.0, and if you
drop the -lplplot when linking psd_drv.so, then you can't run the ps
driver inside a java example, right?

So, I have done some work on this infrastructure, but I would like to
see a clear before and after proof that it's being used, and working
correctly.  

Alan (or anyone), exactly how should I configure and run to exercise
the python binding with dyndrivers?

-- 
Geoffrey Furnish         fu...@ga...

RE: [Plplot-devel] linking, build issues

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

On Mon, 2 Sep 2002, Geoffrey Furnish wrote:

> Okay, I stuided this a little after getting some zzz's, and its not
> what I thought.
>
> I got thorugh this by setting LD_LIBRARY_PATH so that it would find
> the prefix area that I'm building against.  My memory is foggy, did we
> ordinarily have to do this before?  Intuitively, I would expect the
> software to build without LD_LIBRARY_PATH set, but probably not run
> without it set (for prefixen not listed in ld.so.conf).  But usually I
> have my LD_L_P set to the prefix in my .cshrc, but this came up this
> time because I'm setting up a new prefix area.

I had e-mail all prepared about my independent guess that LD_LIBRARY_PATH
was the answer for non-standard itcl, itk library locations, but great
minds think alike!

Here is my mental model of what is going on. For the old style linking of
applications where every library was mentioned, the libraries were found by
the linker using the -L option.  For the new hierarchical style linking, the
application simply links against libplplottcltk.  But I guess the linker
really needs to know the location of every library that libplplottcltk (not
the application) is linked with.  So for non-standard library locations of
libitcl, libitk, etc., you must use LD_LIBRARY_PATH just as you would when
running the application.

I am really glad that you now have dynamic drivers working under Linux.
Please take this week to throw every test you can think of at the current
system including all the dynamic loading of libraries under tclsh and wish.
If those tests work, and you and Joao are happy with the underlying linking
design *for Linux*, then I think the next step is to make non-dynamic
drivers work for shared libraries under Linux.

Alan

Re: [Plplot-devel] linking

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

On Sun, 1 Sep 2002, Geoffrey Furnish wrote:

> I'm really happy to read of the progress on dynloading of PLplot into
> Tcl, and of the progress on dynlinking the libraries, and all this
> better library organization and so forth.
>
> I think it is very important to keep the code building in static
> configuration, since that is all we support on most platforms.  In
> particular, I need the code to keep working on Solaris.  As a
> secondary matter, I want to get dynlinking (shared libs) on Solaris at
> the earlist possible moment, but until then, I think it is critically
> important to keep static linking working on all platforms.

Certainly, by the time of the next release we must have cross-platform
linking that is working properly for Unix/Linux, but for me the first
priority was to get consensus for the linking of shared libraries under
Linux. To further that effort, I felt it was important to use CVS HEAD to
present working (at least on Linux) shared library linking solutions for
discussion and refinement.  Until that process was completed, I presumed
PLplot 5.1.0 would serve everybody's mission critical cross-platform needs.

However, if that presumption is wrong and you need a feature that is
currently only in CVS HEAD for your mission-critical cross-platform work, it
wouldn't be too difficult for you to change one or two configuration lines
(as I recall, I just commented them out and left the infrastructure in
place) to add a long list of libraries to any application link step as a
temporary measure. I believe it is that "long-list" approach for linking
applications that makes everything sort of work cross-platform.  Such a
change should only temporararily interfere with my hierarchical linking
approach for the applications, but should not affect the hierarchical
linking of the libraries.

Alan

[Plplot-devel] dependencies not fully working

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

HI,

I'm documenting this to the list mainly so we don't forget it.  This
may be something that falls on me, but since there's been a lot of
work on the config system lately, and since I /thought/ I had this
working in the past, I'll post it here:

I did a full build, then:

[furnish@dhcp-814-13 tmp]$ touch xwin.c
[furnish@dhcp-814-13 tmp]$ make -n
gcc -fPIC -c          -O    -I. -I/home/furnish/xenon/include -MD -MF
shared/.d.xwin -MP -c xwin.c -o shared/xwin.o
gcc -shared -fPIC -o drivers/xwin_drv.so shared/xwin.o
-L/home/furnish/xenon/lib -ltcl8.3 -ltk8.3 -L/usr/X11R6/lib -lX11
-L. -lplplottcltk -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp
[furnish@dhcp-814-13 tmp]$ make
gcc -fPIC -c          -O    -I. -I/home/furnish/xenon/include -MD -MF
shared/.d.xwin -MP -c xwin.c -o shared/xwin.o
gcc -shared -fPIC -o drivers/xwin_drv.so shared/xwin.o
-L/home/furnish/xenon/lib -ltcl8.3 -ltk8.3 -L/usr/X11R6/lib -lX11
-L. -lplplottcltk -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp

The make -n made me suspicious, the make confirmed it.  Dependencies
are only firing for shared things, not for static (non -fPIC) build
products.  What is supposed to happen is that both xwin.o's should be
produced, and the static lib rebuilt, etc.

-- 
Geoffrey Furnish         fu...@ga...

Re: [Plplot-devel] RE: [Plplot-cvs] CVS update notice (plplot/cf)

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

On Mon, 2 Sep 2002, Geoffrey Furnish wrote:

> Alan W. Irwin writes:
>  > Update of /cvsroot/plplot/plplot/cf
>  > In directory usw-pr-cvs1:/tmp/cvs-serv14482
>  >
>  > Modified Files:
>  > 	configure.in dyndrv.in
[...]
>  > This change gives no linker errors and fine results for directly loaded
>  > examples such as x01c, but dynamically loaded examples from python (and
>  > apparently from java also according to the warnings in the comments about
>  > this) no longer work.
>
> Uhbabubabuh.  What's the story on this?  Has this been resolved?
> There are a bunch of RTLD_* flags (see man dlopen) that come into play
> here.  It's pretty important that dyndrivers keep working inside a
> jvm, methinx.  Has this been resolved (I'm still catching up on plplot
> email).

Yes, it has been resolved.  My guess is this problem is the result of a bug
in the way java and python dlopen libplplot under Linux.  When the driver is
dlopened, libplplot has already been dlopened.  Thus, if the appropriate
RTLD flag were used on the *libplplot* dlopen by java or python, it shouldn't
really be necessary to link the drivers with libplplot. However, I expect
that flag is missing because when you do link the drivers with libplplot the
problem with python and java disappeared.

BTW, I am now comfortable with linking the drivers with libplplot (or
libplplottcltk as appropriate) because it is entirely consistent with the
linking pattern that works in all other cases. That is, if *explicit*
linking dependencies appear in any shared object (and of course every driver
depends on either libplplot or libplplottcltk), then the appropriate library
must be linked when the shared object is created.  But that explicit
dependency case is the *only* library linking that is necessary.  In
particular, so as not to obfuscate the required linking, I have removed all
the unneeded library linking that has been put in in the past so you will
see some greatly simplified linking lines under Linux now.


>  > None of the
>  > results of this change make sense to me so more discussion will be
>  > required on list to get this straightened out.

In future, I gotta be careful of such statements in commit messages...;-) It
makes much more sense to me now.

>
> I haven't yet formulated an opinion of what I think about all this
> "drivers as libraries" business.  My gut says the JNI "ENV" thing is
> the right way to solve these issues, and leave drivers as drivers, and
> libraries as libraries.  But I"m not caught up yet, so I won't declare
> this to be my final opinion yet.

As far as the linker is concerned, they are all shared objects which can be
linked at run-time or dlopened (dynamically linked).  So from that point of
view there is absolutely no distinction between (dynamic) drivers and
libraries.  However, there is one important distinction that we have to keep
in mind for ourselves; we know in advance that all drivers depend on
libplplot or libplplottcltk so to avoid circular dependencies it is
important that nothing in those libraries depends explicitly on anything in
the drivers.  Maurice solved that problem for the xwin driver by using
an escape function approach.  In the tkwin case, it was solved by moving
objects from libplplottcltk to the tkwin shared object.

Alan

RE: [Plplot-devel] linking, build issues

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

Geoffrey Furnish writes:
 > gcc   pltcl.o -L. -lplplottcltk \
 > -o pltcl   -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp
 > /usr/bin/ld: warning: libitcl3.2.so, needed by ./libplplottcltk.so,
 > not found (try using -rpath or -rpath-link)
 > /usr/bin/ld: warning: libitk3.2.so, needed by ./libplplottcltk.so, not
 > found (try using -rpath or -rpath-link)
 > pltcl.o: In function `AppInit':
 > pltcl.o(.text+0x13e): undefined reference to `Itcl_Init'
 > ./libplplottcltk.so: undefined reference to `Itk_Init'
 > collect2: ld returned 1 exit status
 > make: *** [pltcl] Error 1
 > 
 > I haven't had a chance to review the core reasons for the build
 > failures, but superficially it looks like there's been some changes to
 > the ldflags make macro, which haven't been completely worked through
 > in all the cases.  
 > 
 > I can't really drop itcl/itk for my current need, because this is an
 > itk based app which seeks to embed a plframe (inside a PLXWin).  

Okay, I stuided this a little after getting some zzz's, and its not
what I thought.

I got thorugh this by setting LD_LIBRARY_PATH so that it would find
the prefix area that I'm building against.  My memory is foggy, did we
ordinarily have to do this before?  Intuitively, I would expect the
software to build without LD_LIBRARY_PATH set, but probably not run
without it set (for prefixen not listed in ld.so.conf).  But usually I
have my LD_L_P set to the prefix in my .cshrc, but this came up this
time because I'm setting up a new prefix area.

-- 
Geoffrey Furnish         fu...@ga...

RE: [Plplot-devel] Problem solved! (Was: Help needed for dynamic linking problem on linux)

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

Okay, from my inbox, looks like nobody replied to Alan on this topic, but himself.

Alan W. Irwin writes:
 > On Sun, 14 Jul 2002, Alan W. Irwin wrote:
 > 
 > > ==17017== discard syms in /home/software/plplot_cvs/HEAD/plplot_working3/tmp/drivers/psd_drv.so due to munmap()
 > > ==17017== discard 0 (0 -> 0) translations in range 0x43ADB000 .. 0x43AE1FFF
 > > Unable to load driver: psd_drv.so.
 > > Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: cannot open shared object file: No such file or directory
 > 
 > 
 > Update: The discard sysm and discard 0 messages are legit, but the reason is
 > wrong.  What's going on here is ./drivers/psd_drv.so fails in plplot/tmp so
 > the plcore code tries a second time in the install location which I had
 > cleaned out so that fails as well with that resulting error message.  If I
 > simply copy ./drivers/psd_drv.so to the install location, I get the correct
 > error message:
 > 
 > Unable to load driver: psd_drv.so.
 > Reason: /usr/local/plplot/lib/plplot5.1.0/data/../drivers/psd_drv.so: undefined symbol: plRotPhy
 > 
 > What's going on is that psd_drv.so has some undefined symbols (presumably
 > plRotPhy is the first of these to be encountered) 

And I did a search once, which I reported on to the list some months
back, which showed there were some others, I forget exactly which
ones.  It's a small set, but one thing I concluded was that really
there could be more, and a family of "driver support utility
functions" in libplplot could be useful, and expanded to cover some
more cases.  Like, for example, all the coord mapping stuff needed for
viewport selection and transformation stuff inside interactive
drivers, etc.  Well, something like that is probably what is happening
here with plRotPhy, but anyway, I'm saying, one could easily imagine a
formalized and expanded collection of such things, for the purpose of
bringing more useful, and similarly-behaving functionality, to all the
interactive drivers.  There might even be useful stuff that could be
factored out from the non-interactive drivers, and stored in a
driver-support collection inside libplplot.

 > from libplplot that cannot
 > be resolved by the dynamic loader despite the fact that libplplot has
 > already been dynamically loaded.  My best guess for the cause of this is
 > that python (and java) use dlopen to load libplplot in the first
 > place, 

Well, and it's not just things that explicitly use dlopen.  There is
also ld.so which sets up the initial process image.  Similar effects
can come into play even in more ordinary settings, which is why all
the RTLD_* flags are there, to help you control the way the loader
reacts to linked libraries.

 > and
 > they do not use the RTLD_GLOBAL flag which can be ORed with the RTLD_NOW or
 > RTLD_LAZY options for dlopen.  The point of RTLD_GLOBAL is "the external
 > symbols defined in the library will be made available to subsequently loaded
 > libraries" according to the excellent documentation I found at
 > http://www.tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html.
 > Presumably, the dynamic loader invoked when libplplot is simply used as a
 > shared library (i.e., when x??c is invoked) effectively sets this flag so
 > that libplplot symbols such as plRotPhy can be resolved in psd_drv.so.
 > 
 > So my tentative conclusion is that the dlopen calls in the python extension
 > interface (and the java equivalent) forgot to OR in RTLD_GLOBAL with their
 > dlopen flag (since dlopening a library which in turn dlopens another library
 > depending on the symbols of the first library is a scenario they probably
 > didn't think about).

I pondered deeply about this before.  I'm guessing "forgot" isn't what
happened.  My conclusion was they probably don't allow this for some
annoying excuse relating to security.  I remember following some of
the linux kernel traffic back when ELF was coming on line, and ld.so
was getting its revamp, and David Engel and the EYC were going back
and forth on all the issues with LD_LIBRARY_PATH and ld.so.cache and
all that.  Turns out there are some realy amazingly subtle ways to
trojan horse a system that uses shared objects and dynamic linking.

So, when looking closely at how Sun expects you to get along with Java
and external code, I think the answer to this comumdrum is exemplified
in the way that JNI clients interact with the JVM.  Note that we do
not have to link Java C interface code (JNI code) to "libjava" in
order to do our magic.  This is really an impressive achievement, and
I personally believe (and this is admittedly speculation, since I
don't have any contacts inside Sun to check this with), that it was
done specifically in order to overcome this issue of RTLD_* interplay
with dynloading.

What they do is pass a struct to your jni code.  This struct is called
the "env" struct, which is how your JNI code learns everything about
the environment of the JVM process context in which it is executing.
This struct is populated (initialized) with a collection of function
pointers, which your JNI code uses in order to invoke functions in the
JVM.  This effectively eliminates the need to link JNI client code
against any hypotehtical "libjava", and yet it allows you to call jni
support code that is infact burried in the jvm.  Way cool.  I
personally believe this solution was the result of a serious software
engineering effort, and not just a dullard's hack, or the blundering
bumblefussing concoction of people lacking in creativity.

So, coming back to PLplot.  What I think we shoudl do here, to finally
and fully resolve this and all such related issues, is to employ this
same approach inside PLplot.  In fact, we are already sort of doing
something like this, since the dispatch table is sort of like the env
struct, albeit the dispatch table is only used inside plcore.  But the
point is, we load up some structs with function pointers, and deref
them during the course of action, to get work done.  I'm saying we can
embellish this appraoch to do a little more.

What I envision is a PLenv struct, which has a bunch of function
pointer members that are initialized to point to a collection of
PLplot provided "driver support functions".  plRotPhy would be one
example of these, but there should be a few more entries in the PLenv
table to cover other reasonable things drivers might want to do, which
could be implemented in a driver-neutral manner and provided in
libplplot proper.  So, we init this struct, and then pass it along to
the drivers when we call them.  

One way this could be accomplished without too much disruption in the
APIs of all these things, would be to add the PLenv member to the
PLStream, which is already being passed to all the drivers when we
call the driver entry point functions.  The alternative of adding a
PLenv argument to the calling interface of all the public driver entry
point functions, would mean a lot of gratuitous changes to the code,
and something would probably be destabilized.

You could also imagine just adding the function pointer members
directly to PLStream.  If anyone feels strongly about this, I'd be
willing to go either way, with some arm twisting.  But I propose
having a seperate struct PLenv with one struct PLenv * member in
PLStream, just to reduce the memory footprint of the total solution,
and also to evoke some mental continuity with the JNI env thing upon
which it is modelled.

So, this would allow us to drop linking directly any drivers to
libplplot.

I also do not believe that libplplot should be linked to any drivers.
I haven't been able to understand with complete certainty, if this
goal has or has not been achieved yet in the current situation.

 > Bottom line: gotta work around this problem myself.  The solution which I
 > have just committed is to have libplplot link to the "special" drivers tk,
 > xwin, and tkwin and all other "ordinary" drivers link the other way to
 > plplot.  My spot checks indicated everything works with this solution.

Let me know what you think of the above.  We've discussed my jni env
thing before, but I think now you'll be able to understand my proposal
better than when we discussed it before.  What do you think now?

 > Status: there are still some things to clean up.  For example, I
 > just committed a bugfix for plplot.h which solves one bug and also
 > now allows (at least from my preliminary tests) tk to be moved from
 > the special to the ordinary list.  Also, the install has to be
 > fixed up to deal with the special dynamic drivers.  But
 > fundamentally, I think I have the dynamic driver linking problems
 > whipped.

Great progress, thanks.

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] RE: [Plplot-cvs] CVS update notice (plplot/cf)

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

Alan W. Irwin writes:
 > Update of /cvsroot/plplot/plplot/cf
 > In directory usw-pr-cvs1:/tmp/cvs-serv14482
 > 
 > Modified Files:
 > 	configure.in dyndrv.in 
 > Log Message:
 > New name for dynamic drivers:  drivers/*.drv ==> drivers/*_drv.so.
 > (For one key test case valgrind was getting confused by the lack of ".so"
 > on the ends of the driver dll's so I decided to put such a name-ending in
 > there in case there was a similar dynamic loader assumption that was
 > giving us the pecular results discussed below.)
 > 
 > Configuration support for linking libplplot against the tk, xwin, and tkwin
 > dynamic drivers.
 > 
 > In dyndrv.in commented out the link of all drivers against libplplot and
 > also got rid of the corresponding Makefile dependencies.  This change was
 > necessary to remove a circular Makefile dependency (libplplot depends on tk,
 > xwin, and tkwin dynamic drivers while those drivers depend in turn on
 > libplplot.) 
 > 
 > This change gives no linker errors and fine results for directly loaded
 > examples such as x01c, but dynamically loaded examples from python (and
 > apparently from java also according to the warnings in the comments about
 > this) no longer work.  

Uhbabubabuh.  What's the story on this?  Has this been resolved?
There are a bunch of RTLD_* flags (see man dlopen) that come into play
here.  It's pretty important that dyndrivers keep working inside a
jvm, methinx.  Has this been resolved (I'm still catching up on plplot
email).

 > Also after this change valgrind started complaining about the name
 > of the dynamic driver (so I changed it as above).  

Mmm, I should've known that would eventually bite us.  I was just
tickled pink when I learned dlopen could open a file regardless of
name, and I thought .drv was better than .so, so people wouldn't think
the drivers were "libraries" :-).  <chuckle>.

 > None of the
 > results of this change make sense to me so more discussion will be
 > required on list to get this straightened out.

I haven't yet formulated an opinion of what I think about all this
"drivers as libraries" business.  My gut says the JNI "ENV" thing is
the right way to solve these issues, and leave drivers as drivers, and
libraries as libraries.  But I"m not caught up yet, so I won't declare
this to be my final opinion yet.

-- 
Geoffrey Furnish fu...@ga...

[Plplot-devel] linking, build issues

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

BTW, I reconfigured --enable-dyndrivers, but it still doesn't build:

[...]
gcc -shared -fPIC -o ../libplplottcltk.so.5.1.0 \
-Wl,-soname -Wl,libplplottcltk.so.5 \
tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o  tclMain.o  tkMain.o
-L.. -lplplot -ltclmatrix \
 -L/home/furnish/xenon/lib -ltcl8.3 -litcl3.2 -ltk8.3 -litk3.2
-L/usr/X11R6/lib -lX11 -ldl -lm -Wl,-rpath
-Wl,/home/furnish/devel/plplot/tmp
ln -sf libplplottcltk.so.5.1.0 libplplottcltk.so.5
ln -sf libplplottcltk.so.5 libplplottcltk.so

gcc -c          -O    -I. -I/home/furnish/xenon/include -MD -MF
.d.plrender -MP -c plrender.c -o plrender.o
gcc   plrender.o -L. -lplplot -o plrender \
         -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp
gcc -c          -O    -I. -I/home/furnish/xenon/include -MD -MF
.d.pltek -MP -c pltek.c -o pltek.o
gcc   pltek.o -o pltek -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp
gcc -c          -O    -I. -I/home/furnish/xenon/include -MD -MF
.d.pltcl -MP -c pltcl.c -o pltcl.o
gcc   pltcl.o -L. -lplplottcltk \
-o pltcl   -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp
/usr/bin/ld: warning: libitcl3.2.so, needed by ./libplplottcltk.so,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libitk3.2.so, needed by ./libplplottcltk.so, not
found (try using -rpath or -rpath-link)
pltcl.o: In function `AppInit':
pltcl.o(.text+0x13e): undefined reference to `Itcl_Init'
./libplplottcltk.so: undefined reference to `Itk_Init'
collect2: ld returned 1 exit status
make: *** [pltcl] Error 1

I haven't had a chance to review the core reasons for the build
failures, but superficially it looks like there's been some changes to
the ldflags make macro, which haven't been completely worked through
in all the cases.  

I can't really drop itcl/itk for my current need, because this is an
itk based app which seeks to embed a plframe (inside a PLXWin).  

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] linking

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

I'm really happy to read of the progress on dynloading of PLplot into
Tcl, and of the progress on dynlinking the libraries, and all this
better library organization and so forth.

I think it is very important to keep the code building in static
configuration, since that is all we support on most platforms.  In
particular, I need the code to keep working on Solaris.  As a
secondary matter, I want to get dynlinking (shared libs) on Solaris at
the earlist possible moment, but until then, I think it is critically
important to keep static linking working on all platforms.

-- 
Geoffrey Furnish         fu...@ga...

[Plplot-devel] Prescriptions for running tkdemos.tcl under wish and tcldemos.tcl under tclsh

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

While writing e-mail to Geoffrey on the current status of PLplot, I had a
blinding flash of insight....;-)

A side benefit of the current library changes is we can now run tkdemos.tcl
from wish and tcldemos.tcl from tclsh! (This was the major motivation for
working on the tea branch for me.)

Here is the wish/tkdemos.tcl prescription from plplot/tmp:

wish

load drivers/tkd_drv.so Pltk
package require Pltk
source tkdemos.tcl

1
2
3
.....

Please try this for yourself as well. Note, that the version string that the
package require comes back with is 4.99 so something has to be changed to
address that (minor?) issue.

Here is the tclsh/tcldemos.tcl prescription from plplot/tmp:

tclsh

load ./libplplottcltkd.so.5.1.0 Pltcl
package require Pltcl
plinit
source tcldemos.tcl

1
2
3
.....

Please try this for yourself as well. Here the version string returned by
the package require command is correct.

Also some changes will have to be done to the files which set up tcl/tk so
that the package require commands will work without the prior load commands
both for the plplot/tmp and installed versions.  However, I will leave that
internal tcl/tk configuration issue to the tcl/tk experts here.

The important thing to recognize here is that we are now in a position to
run our tk examples directly from a tk environment (wish) and our tcl
examples directly from a tcl environment (tclsh) much in the same way that
we run our python examples directly from python.  Personally, I think this
is an idea our users will understand better than demanding they use special
executables (plserver instead of wish and pltcl instead of tclsh) to gain
access to plplot from tcl/tk.

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] version info, runalldemos.tcl, etc.

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

Geoffrey Furnish writes:
 > Alan W. Irwin writes:
 >  > The other remaining issue I forgot to mention last time was the
 >  > bindings/tcl/pltclgen perl script that won't work for you because of
 >  > line-ending issues.  I assume that should be straightforward since perl has
 >  > had to deal with these sorts of issues forever.  However, that will probably
 >  > take somebody familiar with perl (Geoffrey?) to figure this out.
 > 
 > I am trying to get caught up after a looooooooooooooong diversion.
 > Has this been fixed, or is it still waiting for me?

I put in a fix for this, although haven't heard back whether it does the job
or not.

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