plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] plplot_AT under Linux RH 7.3

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

Alan W. Irwin writes:
 > I will answer the rest later, but to get you started again, it looks like
 > there is a blank between the -L option and the path.  I think they have to
 > be jammed together (at least that is what man ld says).  So there is
 > probably some problem with sysloc.in (or configure.ac) that inserts a blank
 > prefix in the path.  In my case I am using default library locations for the
 > tcl/tk libraries so I don't exercise that logic.

That did the trick, thanks.  Hmm.. I seem to recall that some systems permit
there to be a blank.  Anyway, onward ho.

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

Re: [Plplot-devel] plplot_AT under Linux RH 7.3

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

On Sun, 22 Dec 2002, Maurice LeBrun wrote:

> Maurice LeBrun writes:

> Here's another example of $prefix/lib (in this case /home/mjl/tools/lib)
> being "lost" in the link line:

I think it is again a problem with the leading blank in the path string.

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] plplot_AT under Linux RH 7.3

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

On Sun, 22 Dec 2002, Maurice LeBrun wrote:

> b) Problem building libplplottcltk:
>
> /bin/sh ../../libtool --mode=link gcc  -g -O2   -o libplplottcltk.la -rpath
> /home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib
> -no-undefined -L /home/mjl/tools/lib -ltcl8.3 -L /home/mjl/tools/lib -litcl3.2
> -L /home/mjl/tools/lib -litk3.2 -L /home/mjl/tools/lib -ltk8.3 -L../../src
> -lplplot -L. -ltclmatrix tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo
> tcpip.lo tkMain.lo
>
> rm -fr .libs/libplplottcltk.la .libs/libplplottcltk.* .libs/libplplottcltk.*
>
> gcc -shared  tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo
> tkMain.lo  -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/src/.libs -Wl,--rpath
> -Wl,/home/mjl/dev/plplot/latest/bindings/tcl/.libs -Wl,--rpath
> -Wl,/home/mjl/tools/lib  -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3
> -litcl3.2 -litk3.2 -ltk8.3 -L/home/mjl/dev/plplot/latest/src
> /home/mjl/dev/plplot/latest/src/.libs/libplplot.so
> /home/mjl/dev/plplot/latest/bindings/tcl/.libs/libtclmatrix.so    -Wl,-soname
> -Wl,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.1.0
> /usr/bin/ld: cannot find -litcl3.2
> collect2: ld returned 1 exit status
> make[2]: *** [libplplottcltk.la] Error 1
>
> Here the problem is that the -L /home/mjl/tools/lib wasn't emitted from
*********************************^

> libtool, but I have no idea why.

I will answer the rest later, but to get you started again, it looks like
there is a blank between the -L option and the path.  I think they have to
be jammed together (at least that is what man ld says).  So there is
probably some problem with sysloc.in (or configure.ac) that inserts a blank
prefix in the path.  In my case I am using default library locations for the
tcl/tk libraries so I don't exercise that logic.

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] plplot_AT under Linux RH 7.3

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

Maurice LeBrun writes:
 > 3. The build.  
 > ...
 > b) Problem building libplplottcltk:
 > 
 > /bin/sh ../../libtool --mode=link gcc  -g -O2   -o libplplottcltk.la -rpath
 > /home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib
 > -no-undefined -L /home/mjl/tools/lib -ltcl8.3 -L /home/mjl/tools/lib -litcl3.2
 > -L /home/mjl/tools/lib -litk3.2 -L /home/mjl/tools/lib -ltk8.3 -L../../src
 > -lplplot -L. -ltclmatrix tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo
 > tcpip.lo tkMain.lo  
 > 
 > rm -fr .libs/libplplottcltk.la .libs/libplplottcltk.* .libs/libplplottcltk.*
 > 
 > gcc -shared  tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo
 > tkMain.lo  -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/src/.libs -Wl,--rpath
 > -Wl,/home/mjl/dev/plplot/latest/bindings/tcl/.libs -Wl,--rpath
 > -Wl,/home/mjl/tools/lib  -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3
 > -litcl3.2 -litk3.2 -ltk8.3 -L/home/mjl/dev/plplot/latest/src
 > /home/mjl/dev/plplot/latest/src/.libs/libplplot.so
 > /home/mjl/dev/plplot/latest/bindings/tcl/.libs/libtclmatrix.so    -Wl,-soname
 > -Wl,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.1.0
 > /usr/bin/ld: cannot find -litcl3.2
 > collect2: ld returned 1 exit status
 > make[2]: *** [libplplottcltk.la] Error 1
 > 
 > Here the problem is that the -L /home/mjl/tools/lib wasn't emitted from
 > libtool, but I have no idea why.

Here's another example of $prefix/lib (in this case /home/mjl/tools/lib)
being "lost" in the link line:

/bin/sh ../../libtool --mode=link gcc  -g -O2   -o libtclmatrix.la -rpath
/home/mjl/tools/lib -version-info
 6:0:1 -rpath /home/mjl/tools/lib -no-undefined -L /home/mjl/tools/lib
-ltcl8.3 tclMatrix.lo matrixInit.lo 
 
rm -fr .libs/libtclmatrix.la .libs/libtclmatrix.* .libs/libtclmatrix.*

gcc -shared  tclMatrix.lo matrixInit.lo
-L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3  -Wl,-soname -
Wl,libtclmatrix.so.5 -o .libs/libtclmatrix.so.5.1.0

Not good, as the version I have of tcl8.3 under $prefix/lib is the one
I want to link against, and this line causes the tcl lib under /usr/lib
to be used instead.

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

[Plplot-devel] plplot_AT under Linux RH 7.3

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

Getting started: I built & installed tcl, tk, itcl, BLT, into a new directory
~/tools to be used as prefix for these tests.  Then made a tar copy of it in
its pristine state so I could blow it away and start fresh as needed.  Fresh
checkout of plplot from HEAD.

Note I have little prior experience with AM/LT and am just trying to follow
the prescription and otherwise figure things out as I go along.  I'm currently
stumped (see 3b) so please see that first then look at the rest at your
leisure.


1. Running bootstrap.  Ran into problems with my existing versions of autoconf,
automake, and libtool.  They were all versions at or beyond what was given in
http://sourceforge.net/mailarchive/forum.php?thread_id=1375571&forum_id=2199,
but apparently not sufficiently in sync with each other.  But that's a problem
for lots of packages (certain versions of itcl only working with certain
versions of tcl, etc).

The first time I got:

ged$ ./bootstrap.sh 
aclocal: configure.ac: 474: macro `AM_PATH_PYTHON' not found in library

and after upgrading automake, then:

ged$ ./bootstrap.sh 
aclocal: configure.ac: 430: macro `AM_PROG_LIBTOOL' not found in library

So I upgraded to all the latest stable versions:

autoconf-2.57.tar.gz
automake-1.7.tar.gz
libtool-1.4.3.tar.gz

and finally got through a bootstrap.sh OK, albeit with the following
messages:

ged$ ./bootstrap.sh 
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.

WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':

WARNING:   AC_DEFINE([NEED_MAIN], 1,
WARNING:             [Define if a function `main' is needed.])

WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.


2. configuration issues.

a) (OLD PROBLEM) Get this under newer versions of autoconf:

checking itclDecls.h usability... no
checking itclDecls.h presence... yes
configure: WARNING: itclDecls.h: present but cannot be compiled
configure: WARNING: itclDecls.h: check for missing prerequisite headers?
configure: WARNING: itclDecls.h: proceeding with the preprocessor's result
configure: WARNING:     ## ------------------------------------ ##
configure: WARNING:     ## Report this to bug...@gn.... ##
configure: WARNING:     ## ------------------------------------ ##


b) (OLD PROBLEM)

checking for tclInt.h... no
warning: can't find tclInt.h, setting enable_tkwin to no


c) (OLD PROBLEM) This is wrong, since I do have libvga:

checking for libvga... no
warning: can't find libvga, setting enable_linuxvga to no


d) (NEW PROBLEM) Problem finding vfork.h:

checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no

e) (NEW PROBLEM) It doesn't find my KAI C++ compiler:

CXX:            g++ 

My code to do this was previously in cf/sysconf.in, which doesn't appear to
be used any more.  Explanation?  Just curious, I should be able to suck
in that code by trial and error.


3. The build.  

a) Went mostly well but it sure is busy!  I previously had code to
eliminate redundant -I options but unfortunately that's not there any more,
making the build a lot less clean looking (i.e. harder to see what's going
on).

E.g. in this case the compile has 1 redundant -I../../include and 2 redundant
-I/home/mjl/tools/include.

gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../libltdl
-I/home/mjl/tools/include -I/home/mjl/tools/include -I/home/mjl/tools/include
-g -O2 -MT tkMain.lo -MD -MP -MF .deps/tkMain.Tpo -c ../tk/tkMain.c -o
tkMain.o >/dev/null 2>&1

The link also would have redundant -L options, but it looks like libtool
is filtering them out.

b) Problem building libplplottcltk:

/bin/sh ../../libtool --mode=link gcc  -g -O2   -o libplplottcltk.la -rpath
/home/mjl/tools/lib -version-info 6:0:1 -rpath /home/mjl/tools/lib
-no-undefined -L /home/mjl/tools/lib -ltcl8.3 -L /home/mjl/tools/lib -litcl3.2
-L /home/mjl/tools/lib -litk3.2 -L /home/mjl/tools/lib -ltk8.3 -L../../src
-lplplot -L. -ltclmatrix tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo
tcpip.lo tkMain.lo  

rm -fr .libs/libplplottcltk.la .libs/libplplottcltk.* .libs/libplplottcltk.*

gcc -shared  tclAPI.lo tclMain.lo Pltk_Init.lo plframe.lo plr.lo tcpip.lo
tkMain.lo  -Wl,--rpath -Wl,/home/mjl/dev/plplot/latest/src/.libs -Wl,--rpath
-Wl,/home/mjl/dev/plplot/latest/bindings/tcl/.libs -Wl,--rpath
-Wl,/home/mjl/tools/lib  -L/home/mjl/dev/plplot/latest/bindings/tcl -ltcl8.3
-litcl3.2 -litk3.2 -ltk8.3 -L/home/mjl/dev/plplot/latest/src
/home/mjl/dev/plplot/latest/src/.libs/libplplot.so
/home/mjl/dev/plplot/latest/bindings/tcl/.libs/libtclmatrix.so    -Wl,-soname
-Wl,libplplottcltk.so.5 -o .libs/libplplottcltk.so.5.1.0
/usr/bin/ld: cannot find -litcl3.2
collect2: ld returned 1 exit status
make[2]: *** [libplplottcltk.la] Error 1

Here the problem is that the -L /home/mjl/tools/lib wasn't emitted from
libtool, but I have no idea why.


c) What's the deal with all the weird suffices?
 .lo
 .la
 .lai

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

Re: [Plplot-devel] testing PLplot in-place

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

On Sun, 22 Dec 2002, Joao Cardoso wrote:

> But I don't think that we should worry about this now, as the release date is
> approaching and our efforts should be directed to it

Agreed!

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] testing PLplot in-place

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

On Sunday 22 December 2002 08:46, Maurice LeBrun wrote:
> Wow, I finally caught up on all the email generated on the plplot lists=
=2E
> Now time to get down to work..
>
> One comment, about the ongoing discussion about being able to test the
> package "in place", i.e. w/o having to do a make install.  I changed th=
e
> subject heading to be actually relevant. :)
>
> Certainly it is very nice to be able to test the package before install=
ing
> it.  Many packages allow you to do this, but then in many ways they are
> simpler that what we are trying to accomplish.  I would be willing to g=
o
> to substantial lengths to support in-place testing, but if it is actual=
ly
> a Herculean effort.. then no.

We could first discuss the possible approaches and then evaluate the effo=
rt.=20
If no reasonable approach is possible, which I doubt, or if the effort is=
=20
Herculean, then agree to not do it.

What I propose is:
1-to have a "libs" directory (not ".libs", which are scattered among seve=
ral=20
directories)  where all libs will go when a plain "make" is executed;=20
executables will be linked at make time with those libs using rpath. At "=
make=20
install" time, executables and libraries will be relinked to the final=20
destination.

2-The dynamic drivers have to be searched for in at least two places: in =
the=20
build tree first and in the install tree latter; some form of relative=20
addressing should be used in order to avoid that an installed application=
=20
will use the build tree drivers.

3-Other files, such as fonts and maps also have to be searched in differe=
nt=20
places. Other front-ends will have to search for support files in two=20
different places -- this needs to be enumerated before going any further.

4-Plplot uses to have many search paths among the several front-ends, and=
 this=20
effort could be used to clarify them all. Relative addressing could be us=
ed=20
for them all (hmm...)? The library, at init time, could store the locatio=
n=20
where it is (how?), and from that point use relative addressing? This wou=
ld=20
solve point 2 above, as relative addresses are different in the build and=
=20
install tree. But I have not really though about this in detail.

But I don't think that we should worry about this now, as the release dat=
e is=20
approaching and our efforts should be directed to it, as the next to come=
=20
release will probably be in 2004 :-).

>
> At DejaNews I made the call that the developer had to run "make install=
"
> and test out of the install area before the whole thing would work.=20
> Developers would create one or more "play areas" that they'd install th=
e
> code to in order to give it a full workout.  Sometimes you have to choo=
se
> between an clear/elegant build + filesystem layout of the source code a=
nd
> being able to run it in place.  Although the latter is really nice to h=
ave,
> I'll sacrifice it if necessary in order to achieve the former.

I believe that a reasonable compromise is possible, and having the time (=
we=20
don't have deadlines here), we can accomplish it.
My personal problem is that I don't have=20
autoconf/automake/libtool/autotest/autoprogram/autorun/autodestroy (my si=
ck=20
humour ;-) experience. I never needed them for my own work, where a coupl=
e of=20
directories and Makefiles are enough, and I don't anticipate that I will =
ever=20
need, thus I'm reluctant to learn them all.


Joao

[Plplot-devel] testing PLplot in-place

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

Wow, I finally caught up on all the email generated on the plplot lists.
Now time to get down to work..

One comment, about the ongoing discussion about being able to test the package
"in place", i.e. w/o having to do a make install.  I changed the subject
heading to be actually relevant. :)

Certainly it is very nice to be able to test the package before installing
it.  Many packages allow you to do this, but then in many ways they are
simpler that what we are trying to accomplish.  I would be willing to go
to substantial lengths to support in-place testing, but if it is actually
a Herculean effort.. then no.

At DejaNews I made the call that the developer had to run "make install" and
test out of the install area before the whole thing would work.  Developers
would create one or more "play areas" that they'd install the code to in order
to give it a full workout.  Sometimes you have to choose between an
clear/elegant build + filesystem layout of the source code and being able to
run it in place.  Although the latter is really nice to have, I'll sacrifice
it if necessary in order to achieve the former.

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

Re: [Plplot-devel] How to Build PLplot to use with Tcl-tk

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

On Fri, 20 Dec 2002, Alan W. Irwin wrote:
> I believe sys/win-tk is for a cygwin environment, but could Vince confirm
> this please?  If my assumption is true, then sys/win-tk is the recommended
> way to get plplot working for cygwin on windows now. (Of course,
> sys/win32/msdev/ is the recommended way to get plplot working on "bare"
> windows.)

No, win-tk is for Windows.  Going to that directory and typing:

nmake -f makefile.vc
nmake -f makefile.vc install

will build and install the 'Plplotter' extension to Tcl/Tk so that it can
be used from any conventional tcl,tk installation on Windows.

It is nothing to do with cygwin at all.

The difference to 'msdev' is that that stuff builds standalone versions of
plplot (I think) which have nothing in common with tcl,tk.

The problem with compiling anything using cygwin is that to run it, you
also need to have cygwin (not much use if you want to distribute your
software to other people), unless you use some sort of '-mno-cygwin' flag
to gcc, but that just complicates things more.

cheers,

Vince.

Re: [Plplot-devel] How to Build PLplot to use with Tcl-tk

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

On Fri, 20 Dec 2002, Vince Darley wrote:

> Sorry, my last msg was nonsense.  You will need to rebuild the Plplotter
> package for tcl-tk, using the makefile.vc in sys/win-tk.  You will also
> need to edit the plDevs.h file in that directory to enable the drivers you
> want (jpeg), and you will need to make sure any additional libraries and
> header files needed by that driver are accessible.  Only then can you do
> what I suggested in my previous email.
>

I believe sys/win-tk is for a cygwin environment, but could Vince confirm
this please?  If my assumption is true, then sys/win-tk is the recommended
way to get plplot working for cygwin on windows now. (Of course,
sys/win32/msdev/ is the recommended way to get plplot working on "bare"
windows.)

The other much more general method I was discussing for configuring and
building plplot on cygwin uses the same method (configure; make; make
install in the top-level directory) that works on Linux and Unix now.
Unfortunately, the general method doesn't work at the moment for cygwin, but
there is hope in 6 months or so that it will for the reasons I discussed.

I have no cygwin experience myself, but the impression I get from my reading
about the autotools-cygwin problem over the last few days is there is a very
strong effort to port everything in Linux into the cygwin environment.  So
again on a time scale of 6 months or so you may find everything you need
(libgd, libpng, libjpeg, and zlib) already ported to the cygwin environment
which should allow you to produce png and jpeg plots as a matter of routine
in that environment.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Re: [Plplot-general] How to Build PLplot to use with Tcl-tk

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

Hello Pankaj:

You may not be aware of this, but your cross-posting to both plplot_general
and plplot_devel is an annoyance to those who are subscribed to both lists
since we see your posts twice.

My own feeling is you are asking fairly technical questions so your posts
should go to plplot_devel only.

With regard to the content of your particular message, I would know exactly
how to answer you in a Linux environment.  You need libgd, libpng, libjpeg,
and zlib in order to compile the gd.c device driver (which implements the
png and jpeg devices).

The problem with the Plplot windows environment is it is only supported by
one guy (Olof Svensson, who is subscribed to plplot_devel, but is not part
of the core team because of lack of time on his part.) The primary focus of
plplot core development team is oriented toward the Unix/Linux side, and
Olof keeps up as well as he can on the windows side in his spare time.  So
you may have to figure out for yourself how to get the gd device implemented
in that environment.  The first step would be to create libgd for the
windows environment.  For instructions on that, see
http://www.boutell.com/gd/manual2.0.9.html.

If you don't have the time/skills to do that, then there is hope for you in
about another 6 months or so. The natural way to get access to all the
Unix/Linux side developments (such as the gd device driver) in windows is to
use the new configuration scheme to build plplot in a cygwin environment.
(Cygwin is a free implementation of Unix for windows.) Unfortunately, that
does not quite work yet because of current incompatibilities between
autotools and cygwin. We are very close, since everything compiles on Cygwin
without problems, but there seems to be a linking problem which lots of
other projects have also encountered. Since both autotools and cygwin are
developed by the FSF, and people are clamoring for a simple solution, I
fully expect that situation to be resolved on a fairly short time scale.
Thus, I am planning to try testing it again in 6 months or so.

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] How to Build PLplot to use with Tcl-tk

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

Sorry, my last msg was nonsense.  You will need to rebuild the Plplotter
package for tcl-tk, using the makefile.vc in sys/win-tk.  You will also
need to edit the plDevs.h file in that directory to enable the drivers you
want (jpeg), and you will need to make sure any additional libraries and
header files needed by that driver are accessible.  Only then can you do
what I suggested in my previous email.

[NB: I just committed a fixed makefile.vc to cvs]

cheers,

-- Vince

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

Re: [Plplot-devel] How to Build PLplot to use with Tcl-tk

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

I believe that version already comes with jpeg support in its 'gd'
library, and (assuming you downloaded the binary from my web page) it is
compiled in.  You can test this with:

package require Plplotter
plframe .p
pack .p
.p cmd plsdev jpeg

which should not throw an error.  Assuming this is the case, you can use
whatever standard Plplot functions you like, or edit the .tcl scripts
which come with Plplot to provide a more seamless menu-based saving of
jpegs.

cheers,

-- Vince

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


On Fri, 20 Dec 2002, Pankaj Laddha wrote:

> Hi,
>
> I am using PLplot 5.1.0 along with tcl-tk on windows NT. I want PLplot to
> support jpeg format as one of its File output device format as mentioned in the
> user document.
>
> I tried my luck by browsing on plplot mailing list to figure out how can this be
> done but without much success?
>
> Can anyone help me with the procedure to rebuild Plplot on windows NT? I would
> like to use Plplot with JPEG format support with tcl-tk as development language.
>
> Thanks.
>
> Pankaj.
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
> Time is running out!  Thinkgeek.com has the coolest gifts for
> your favorite geek.   Let your fingers do the typing.   Visit Now.
> T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

[Plplot-devel] How to Build PLplot to use with Tcl-tk

[Pankaj L. <pa...@da...>]

Hi,

I am using PLplot 5.1.0 along with tcl-tk on windows NT. I want PLplot to
support jpeg format as one of its File output device format as mentioned in the
user document.

I tried my luck by browsing on plplot mailing list to figure out how can this be
done but without much success?

Can anyone help me with the procedure to rebuild Plplot on windows NT? I would
like to use Plplot with JPEG format support with tcl-tk as development language.

Thanks.

Pankaj.

Re: [Plplot-devel] New java configuration completed and tested and other configuration news

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

On Wednesday 18 December 2002 05:13, Alan W. Irwin wrote:
> On Wed, 18 Dec 2002, Joao Cardoso wrote:

I don't like the way how AT  is setup, but I also don't want to spend one=
 or=20
two weeks learning how to change it.
Do I have to live with it? I don't yet know the answer to this question.

Joao

[Plplot-devel] Shared libraries don't build on Cygwin

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

Vince has tried a number of possibilities with the new configuration scheme.
Everything compiles okay, but it just will not build shared libraries on
cygwin.  The loader there keeps giving the error message "undefined
reference to `_WinMain@16'." If you google for libtool cygwin WinMain you
get a huge number of hits showing this is a common problem for many
autotools configured Unix packages that are being ported to cygwin. Also,
the autobook chapter devoted to cygwin makes it clear both cygwin and
libtool are in a great state of flux trying to meet each others shared
object needs so it is not clear there will be an easy solution to this
common problem until both packages settle down.  Thanks very much, Vince,
for giving this interesting possibility a good try - a brave attempt that
failed at this time but which is likely to succeed in the future since so
many are clamoring for solutions.

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] New java configuration completed and tested and other configuration news

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

On Wed, 18 Dec 2002, Joao Cardoso wrote:

> > An additional issue is the rpath location of libplplot that all extensions
> > must link to.
>
> This is my issue.
>
> > That is automatically taken care of for all extensions that
> > are built by libtool; at build time the build location of libplplot is used
> > and at install time everything is automatically relinked to use the
> > installed location of libplplot.  The only exception to this is the octave
> > plplot extension because currently that particular extension is not built
> > by libtool.
>
> [...] That's why I want to use it -- whatever the system is, using
> mkoctfile guarantees that a module will be correctly built and linked.
> To use it, it must be compiled twice, once for the build tree and again for
> the install tree. This could be simplified, I think, and only relink, not
> recompile.

If you want to stick with mkoctfile that is okay with me, but then you have
to explicitly find the solution for linking a version at build time with a
build rpath and relinking at install time with a install rpath.  I am sure
there is a reasonably straightforward way to do this with the appropriate
automake syntax and time stamp files, but I haven't thought very much about
it since I was concentrating on a different solution.

> > These complicated directions are *only* required if you are using "make
> > check".
>
> How the hell can I test the library, drivers, bindings, and examples? I must
> do a "make check"!

This claim weakens your argument since make check is definitely not
necessary for testing. Instead do the following: cd to the install location
of the c examples, $prefix/lib/plplot5.1.0/examples/c. "make -f
Makefile.examples x01c". (I have mentioned this step before to the list, but
perhaps you failed to notice it?) Run x01c with the variety of drivers you
want to test.  This procedure tests the library, drivers, c binding, and
example. If you want to test other bindings then go to the appropriate
directory in the installed examples instead.  If you want to test all the
non-interactive examples simply run plplot-test.sh, but that is overkill and
running single examples usually does all the testing you need.

Have you ever tried testing this way in the installed location?  If you try
it you may find it is not that bad, and then the whole argument goes away.

>
> > By the way,
> > we are only talking an additional 20 seconds here (at least on my 600MHz
> > machine) to do "make install", and it is substantially less if you limit
> > the configuration to just the features and driver(s) you are testing.
>
> You are talking as a sales man, selling the lower figures :-).

Nope.  I am not trying to sell this at all.  Instead, I am trying to give
you information about my real recent experiences with testing programme
changes with the new configuration scheme.  To expand this information I
decided to time all the steps accurately for you and the others so there is
no mistake about the relatively small amount of time we are discussing here.
Everything done after a rm -rf /usr/local/plplot_at/* and make distclean on
my AMD 600MHz machine.

(1) time ./bootstrap.sh >& bootstrap.out
18.640u 0.390s 0:20.35 93.5%    0+0k 0+0io 7383pf+0w

(2) time ./configure --prefix=/usr/local/plplot_at  \
--enable-dyndrivers --enable-octave --enable-java >& configure.out
17.270u 10.440s 0:32.67 84.8%   0+0k 0+0io 406819pf+0w

Note this configure includes every driver except for linuxvga (missing library
on my system) and gnome and ntk (turned off by default).  Also
tcl/tk, python, c++, f77, java, and octave.

(3) time make >& make.out
174.740u 17.870s 3:45.53 85.4%  0+0k 0+0io 556384pf+0w

(4) time make install >& make_install.out
14.640u 8.040s 0:26.71 84.9%    0+0k 0+0io 282441pf+0w

Before I got ~20 seconds (as I stated) rather than 27 seconds for this step,
but then I probably wasn't installing java and octave.

(5) touch src/plcore.c (emulate a change in plcore.c).

(6) rm -rf /usr/local/plplot_at/*

(7)  time make install >& make_install.out
19.830u 8.910s 0:32.35 88.8%    0+0k 0+0io 309732pf+0w

Steps 5-7 emulate a change in source code. As expected, the make install is
a bit longer than step 4 since plcore.c had to be compiled (I checked this
occurred).  But if you don't configure a lot of different components and
drivers, this ~30 second near worst case latency can be made substantially
smaller. Also note that autotools does very good dependency tracking so when
you change a file a minimum of recompilation and relinking is done for
the install.


> In a real situation, where normally  I have the plplot tree configured for all
> drivers and bindings, if I ocasionaly detect something that needs a change, I
> must wait much longer than that. Only on very specific ocasions I have a
> minimum set of drivers/bindings configured.

See real numbers above for near worst case ~30 sec latency from make install
after a change.  If you do the same tests do you really get much slower
results on your 700MHz machine? Note neither machine is a front end machine
any more and in any case you can get substantially lower latency if you cut
down on unused drivers and front ends.  So my conclusion is not many
developers are going to be bothered that much by this latency.

>
> > > Thus, while I agree that AT is a good thing, there is still work to do
> > > to make our developper life confortable.
> >
> > Although only an additional 20 seconds in the test cycle is involved for
> > developers, such latency is often annoying.  Thus, if you would like to
> > work
>
> If *we* agree that it is annoying, than *we* should work... sorry, you started
> it...

I was trying to "lean over backwards" to understand your concerns.  However,
your argument forced me to look at the timing numbers again, and they
confirm this is not a high priority for my needs (or most other developer's
needs). However, since you obviously do feel this is a high priority, then I
have been willing to cooperate by laying out for you what you have to do in
a fair amount of detail which has taken a substantial amount of my time.
Much of it is C code change such as telling plcore.c where the drivers are
built (see below) or where the font and map data are located.

>
> But I don't want an ad hoc solution such as searching in the .libs
> directories. Only if it is necessary, and its hard to believe that  AT, which
> where made to easy developpers life will end up complicating it.

There is nothing magical or ad hoc about .libs.  That is the standard
subdirectory location in any particular directory where libtool puts its
results.  If that's where the drivers are built, then you have to tell
plcore.c to look in that location.  It is exactly analogous to the old days
where we had plcore look in plplot/tmp as well as the install locations.  It
really is as simple as that.

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] New java configuration completed and tested and other configuration news

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

On Tuesday 17 December 2002 19:54, Alan W. Irwin wrote:
> On Tue, 17 Dec 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
> > On Tuesday 17 December 2002 05:51, Alan W. Irwin wrote:
> > ...
> >
> > | All drivers (configured both dynamically and statically) are also n=
ow
> > | configured with the new scheme. So there should be no further major
> > | additions to the current configuration scheme
> >
> > I don't quite agree. If your AT effort does simplify our (developper)
> > job, by automatically providing plplot on (potentially) new platforms=
,
> > it does turns the development cycle longer and tedious, because the
> > need to "make install".
> >
> > The problem is how to develop in the build tree without the need to
> > install. There are three situations:
> >
> > 1-finding data like fonts, etc. This should be pretty easy, so I woul=
d
> > solve it last.
> >
> > 2-finding libraries: libraries will be found by executables, thanks t=
o a
> > wrapper with the same name of the executable that points to the .libs
> > hidden libraries. This point is also solved, but we must be sure that
> > the build tree library is searched first than an installed library by
> > the executable wrappers.
> >
> > 3-finding drivers: this currently does not work. drivers must be
> > installed, and this means "make && make install" after each
> > modification to a driver. As "make install" also installs other files=
,
> > this might add difficulties to a debugging cycle, see bellow.
>
> This should be as simple as finding the build (as opposed to installed)
> fonts, maps, etc.  The drivers.db file is generated (by configure) in
> plplot/drivers, and all the xxx_drv.so files are built in
> plplot/drivers/.lib.

But I would expect AT to make that. It's hard to belive that developpers =
have=20
to rely on a hidden directory files... and as you are our AT expert...

> > 4-interpreted languages that dlopen they own plplot extensions.
> > Currently Octave only works with plplot installed. I don't know if
> > other languages has the same problem.
>
> One issue is that for every scripting language you have to tell it the
> location of the extension.  But we know exactly where all of these
> extensions are built so it is a straightforward problem to solve.  For
> example, in the python case the installed extensions are found in the
> following way for my configured setup:
>
> (This is the totality of plplot/examples/plplot_python_start.py).
> # Append to effective python path so that can find plplot modules.
> import sys
> sys.path.insert (0, "/usr/local/plplot_at/lib/python2.1/site-packages")
>
> So it is a matter of changing this file if you want to refer to the bui=
ld
> location of the extension.  For octave, I believe you use the -p parame=
ter
> on the octave command to specify the location of the extension. The
> automatic searching for extensions by tcl is still an art rather than a
> science so that will be the most problematic one.  BTW, for tcl there i=
s an
> additional issue of finding the tcl startup scripts in the build locati=
on
> rather than the install location.
>
> An additional issue is the rpath location of libplplot that all extensi=
ons
> must link to.

This is my issue.

> That is automatically taken care of for all extensions that
> are built by libtool; at build time the build location of libplplot is =
used
> and at install time everything is automatically relinked to use the
> installed location of libplplot.  The only exception to this is the oct=
ave
> plplot extension because currently that particular extension is not bui=
lt
> by libtool.

Ah, you mean that if octave modules extension was .so instead of .oct tha=
n the=20
problem would be solved? I could try to use and establish a link.

>  However, privately we discussed how you could build it with
> libtool, and I believe that would completely solve this issue.

Yes, but I didn't gave you the final anwser: mkoctfile is really build fr=
om=20
mkoctfile.in at configure time, after configure and libtool detects the=20
systems peculiarities. Also, mkoctfile if for ordinary users to use, not=20
necessarily to developpers, and all details are thus hidden. So mkoctfile=
=20
enables to build octave modules in all unix systems, win2000, djgpp, win9=
8,=20
macOS, etc. That's why I want to use it -- whatever the system is, using=20
mkoctfile guarantees that a module will be correctly built and linked.
To use it, it must be compiled twice, once for the build tree and again f=
or=20
the install tree. This could be simplified, I think, and only relink, not=
=20
recompile.

> A final issue with getting things to work both in the build and install
> areas is confusion over which you are using.  I don't know how many tim=
es
> in the past I got burned by this issue.  Thus, I strongly suggest we ha=
ve a
> configuration option which allows us to make the choice between either =
the
> build area or installed area with no possible confusion between the two=
=2E

No problem.

> > but to avoid misunderstandings,
> > please "rm -rf <prefix>" before reporting a working binding: in my
> > case, I do "make && make install &&  rm -rf /usr/local/test/bin
> > /usr/local/test/include/ /usr/local/test/python/ /usr/local/test/shar=
e/
> > /usr/local/test/lib/lib* /usr/local/test/lib/plplot5.1.0/tcl". When
> > point 1 and 3 above becomes solved, than a plain "rm -rf <prefix>" wi=
ll
> > be enough.
>
> These complicated directions are *only* required if you are using "make
> check".

How the hell can I test the library, drivers, bindings, and examples? I m=
ust=20
do a "make check"!

By the way, "make check" is generally used to auto-check, where besides b=
eing=20
compiled, the tests are run and its output compared with know good result=
s.=20
In our case the target should be called "make demos". And to avoid the ne=
ed=20
to make all demos, we should have several targets, make cdemos, fdemos,=20
cxxdemos, alldemos, etc.

>  For now to avoid these complications I would advise avoiding "make
> check". Instead, I suggest sticking strictly with using installed resul=
ts
> (i.e., the current development cycle should consist of a programme chan=
ge,
> rm -rf <prefix>, make install, do test in the installed area).

But this is exactly what I'm saying: I'm not satisfied with the current A=
M=20
scheme!

> By the way,
> we are only talking an additional 20 seconds here (at least on my 600MH=
z
> machine) to do "make install", and it is substantially less if you limi=
t
> the configuration to just the features and driver(s) you are testing.

You are talking as a sales man, selling the lower figures :-).

In a real situation, where normally  I have the plplot tree configured fo=
r all=20
drivers and bindings, if I ocasionaly detect something that needs a chang=
e, I=20
must wait much longer than that. Only on very specific ocasions I have a=20
minimum set of drivers/bindings configured.

> > Thus, while I agree that AT is a good thing, there is still work to d=
o
> > to make our developper life confortable.
>
> Although only an additional 20 seconds in the test cycle is involved fo=
r
> developers, such latency is often annoying.  Thus, if you would like to
> work

If *we* agree that it is annoying, than *we* should work... sorry, you st=
arted=20
it...

And I like to reach a consensus of what to do and how before going forwar=
d.=20
When the decisions affects others. I dont ask when I correct a bug or=20
introduce a feature, that makes no sense; but on global issues, I like to=
=20
agree on what to do. This is also the reason why I'm not changing things.=
 (=20
and the total unknowledge on AT, which I would like to keep :()

But I don't want an ad hoc solution such as searching in the .libs=20
directories. Only if it is necessary, and its hard to believe that  AT, w=
hich=20
where made to easy developpers life will end up complicating it.

Anyhow, I don't have the time right now. And at the begining of the next =
year=20
I have to make ready a new discipline course. So it looks that AM will st=
ay=20
as is now.

> on issues 1-4 and the additional issues with using the build area for
> tests that I have discussed, then please go ahead.  However, I don't vi=
ew
> this effort as release critical since it doesn't affect our users,

It will be if they want to test before install. You have to tell them=20
"configure with a test prefix, make, make install. If you like, than=20
configure again with the righ prefix, then make clean, make and make inst=
all=20
again."  I have already used this argument. Not critical, but annoying.=20
Nonetheless this issue I agree with a release at this (near) time.

> and it
> is becoming critical to make the release so our users can enjoy all the=
 bug
> fixes and new features already on CVS HEAD compared to what was availab=
le
> for plplot-5.1.0.  So if you are aware of user-related issues that you
> could fix or improve before the release, I hope you will give them high=
er
> priority than the removal of this developer cycle latency.
>
> Also, please don't freeze PLplot improvements at this time in anticipat=
ion
> of a release. Christmas is fast approaching so I have now resigned myse=
lf
> to some time in January as the earliest possible release date, and it c=
ould
> be indefinitely later than that because nobody at this time has stepped
> forward and taken responsibility for the -dev tk issue or the solaris w=
ith
> tcl/tk test that are currently holding up the release.
>
> Alan
>
> email: ir...@be...
> phone: 250-727-2902=09FAX: 250-721-7715
> snail-mail:
> Dr. Alan W. Irwin
> Department of Physics and Astronomy,
> University of Victoria, P.O. Box 3055,
> Victoria, British Columbia, Canada, V8W 3P6
> __________________________
>
> Linux-powered astrophysics
> __________________________
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Static library build works with the new configuration scheme

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

On Tue, 17 Dec 2002, Alan W. Irwin wrote:

> Also, the octave and python interfaces don't
> work with static libraries.  (I am not sure whether this is expected or not
> since apparently you can use dlopen to open a static library, and that is
> what those front ends presumably use to load their wrapper libraries.)

I investigated this further and python and tclsh both refuse to load the
respective static libraries plplotcmodule.a and libplplottcltk.a. The error
message was something about wrong ELF header.  So this is a fundamental
issue not a configuration issue.  octave is probably a similar case.
mkoctfile does build a shared wrapper library plplot_octave.oct, but that
wrapper is statically linked to libplplot, and that may be the fundamental
source of the trouble in that case.

Anyhow, we are stuck with the fact that static libraries have limitations
for the scripting language front ends that attempt to load them as
extensions.  However, it is nice to know we can build and use them for
compiled language front ends for those platforms where shared libraries
cannot be built.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Static library build works with the new configuration scheme

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

If you use the ./configure option, --disable-shared, then the building of
shared libraries is dropped by the new configure system, and you get static
libraries only.  (For completeness and symmetry I should mention there is an
option, --disable-static to give you shared libraries only.)

I have just tested those static libraries on Linux.  There is one name clash
in x19c.c that I just fixed.  Also, the octave and python interfaces don't
work with static libraries.  (I am not sure whether this is expected or not
since apparently you can use dlopen to open a static library, and that is
what those front ends presumably use to load their wrapper libraries.) But
currently I found that the c, c++, fortran, and tcl interfaces (using pltcl)
do work with static libraries if you don't mind huge executables. To take
one example, with shared libraries x01c is 13.6 K in size.  With static
libraries it is 1MB (!) in size.

So it is nice to know we have working static libraries accessible to us from
the new configuration approach, but because of the size issue it is probably
best to avoid them unless you absolutely need them.

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] New java configuration completed and tested and other configuration news

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

On Tue, 17 Dec 2002, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Tuesday 17 December 2002 05:51, Alan W. Irwin wrote:
> ...
> | All drivers (configured both dynamically and statically) are also now
> | configured with the new scheme. So there should be no further major
> | additions to the current configuration scheme
>
> I don't quite agree. If your AT effort does simplify our (developper)
> job, by automatically providing plplot on (potentially) new platforms,
> it does turns the development cycle longer and tedious, because the
> need to "make install".
>
> The problem is how to develop in the build tree without the need to
> install. There are three situations:
>
> 1-finding data like fonts, etc. This should be pretty easy, so I would
> solve it last.
>
> 2-finding libraries: libraries will be found by executables, thanks to a
> wrapper with the same name of the executable that points to the .libs
> hidden libraries. This point is also solved, but we must be sure that
> the build tree library is searched first than an installed library by
> the executable wrappers.
>
> 3-finding drivers: this currently does not work. drivers must be
> installed, and this means "make && make install" after each
> modification to a driver. As "make install" also installs other files,
> this might add difficulties to a debugging cycle, see bellow.

This should be as simple as finding the build (as opposed to installed)
fonts, maps, etc.  The drivers.db file is generated (by configure) in
plplot/drivers, and all the xxx_drv.so files are built in plplot/drivers/.l=
ib.

>
> 4-interpreted languages that dlopen they own plplot extensions.
> Currently Octave only works with plplot installed. I don't know if
> other languages has the same problem.

One issue is that for every scripting language you have to tell it the
location of the extension.  But we know exactly where all of these
extensions are built so it is a straightforward problem to solve.  For
example, in the python case the installed extensions are found in the
following way for my configured setup:

(This is the totality of plplot/examples/plplot_python_start.py).
# Append to effective python path so that can find plplot modules.
import sys
sys.path.insert (0, "/usr/local/plplot_at/lib/python2.1/site-packages")

So it is a matter of changing this file if you want to refer to the build
location of the extension.  For octave, I believe you use the -p parameter
on the octave command to specify the location of the extension. The
automatic searching for extensions by tcl is still an art rather than a
science so that will be the most problematic one.  BTW, for tcl there is an
additional issue of finding the tcl startup scripts in the build location
rather than the install location.

An additional issue is the rpath location of libplplot that all extensions
must link to. That is automatically taken care of for all extensions that
are built by libtool; at build time the build location of libplplot is used
and at install time everything is automatically relinked to use the
installed location of libplplot.  The only exception to this is the octave
plplot extension because currently that particular extension is not built b=
y
libtool.  However, privately we discussed how you could build it with
libtool, and I believe that would completely solve this issue.

A final issue with getting things to work both in the build and install
areas is confusion over which you are using.  I don't know how many times i=
n
the past I got burned by this issue.  Thus, I strongly suggest we have a
configuration option which allows us to make the choice between either the
build area or installed area with no possible confusion between the two.

> but to avoid misunderstandings,
> please "rm -rf <prefix>" before reporting a working binding: in my
> case, I do "make && make install &&  rm -rf /usr/local/test/bin
> /usr/local/test/include/ /usr/local/test/python/ /usr/local/test/share/
> /usr/local/test/lib/lib* /usr/local/test/lib/plplot5.1.0/tcl". When
> point 1 and 3 above becomes solved, than a plain "rm -rf <prefix>" will
> be enough.

These complicated directions are *only* required if you are using "make
check".  For now to avoid these complications I would advise avoiding "make
check". Instead, I suggest sticking strictly with using installed results
(i.e., the current development cycle should consist of a programme change,
rm -rf <prefix>, make install, do test in the installed area). By the way,
we are only talking an additional 20 seconds here (at least on my 600MHz
machine) to do "make install", and it is substantially less if you limit th=
e
configuration to just the features and driver(s) you are testing.

>
> Thus, while I agree that AT is a good thing, there is still work to do
> to make our developper life confortable.

Although only an additional 20 seconds in the test cycle is involved for
developers, such latency is often annoying.  Thus, if you would like to wor=
k
on issues 1-4 and the additional issues with using the build area for tests
that I have discussed, then please go ahead.  However, I don't view this
effort as release critical since it doesn't affect our users, and it is
becoming critical to make the release so our users can enjoy all the bug
fixes and new features already on CVS HEAD compared to what was available
for plplot-5.1.0.  So if you are aware of user-related issues that you coul=
d
fix or improve before the release, I hope you will give them higher priorit=
y
than the removal of this developer cycle latency.

Also, please don't freeze PLplot improvements at this time in anticipation
of a release. Christmas is fast approaching so I have now resigned myself t=
o
some time in January as the earliest possible release date, and it could be
indefinitely later than that because nobody at this time has stepped forwar=
d
and taken responsibility for the -dev tk issue or the solaris with tcl/tk
test that are currently holding up the release.

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
__________________________

Re: [Plplot-devel] New java configuration completed and tested and other configuration news

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

On Tuesday 17 December 2002 05:51, Alan W. Irwin wrote:
=2E..
| All drivers (configured both dynamically and statically) are also now
| configured with the new scheme. So there should be no further major
| additions to the current configuration scheme

I don't quite agree. If your AT effort does simplify our (developper)=20
job, by automatically providing plplot on (potentially) new platforms,=20
it does turns the development cycle longer and tedious, because the=20
need to "make install".

The problem is how to develop in the build tree without the need to=20
install. There are three situations:

1-finding data like fonts, etc. This should be pretty easy, so I would=20
solve it last.

2-finding libraries: libraries will be found by executables, thanks to a=20
wrapper with the same name of the executable that points to the .libs=20
hidden libraries. This point is also solved, but we must be sure that=20
the build tree library is searched first than an installed library by=20
the executable wrappers.

3-finding drivers: this currently does not work. drivers must be=20
installed, and this means "make && make install" after each=20
modification to a driver. As "make install" also installs other files,=20
this might add difficulties to a debugging cycle, see bellow.

4-interpreted languages that dlopen they own plplot extensions.=20
Currently Octave only works with plplot installed. I don't know if=20
other languages has the same problem, but to avoid misunderstandings,=20
please "rm -rf <prefix>" before reporting a working binding: in my=20
case, I do "make && make install &&  rm -rf /usr/local/test/bin=20
/usr/local/test/include/ /usr/local/test/python/ /usr/local/test/share/=20
/usr/local/test/lib/lib* /usr/local/test/lib/plplot5.1.0/tcl". When=20
point 1 and 3 above becomes solved, than a plain "rm -rf <prefix>" will=20
be enough.

Thus, while I agree that AT is a good thing, there is still work to do=20
to make our developper life confortable.

Joao

PS-No, I will not upgrade my 700MHz P4 :-)

[Plplot-devel] New java configuration completed and tested and other configuration news

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

I have now configured our java interface with the new configuration approach.
The new wrapper library is called libplplotjava.so.  This completes the
move of all interface wrapper code from libplplot to special wrapper libraries
which are built or not depending on the configuration options.

I have done some limited testing of a few java examples to make sure they
are installed okay and can be built properly with the instructions in
$prefix/lib/java/plplot/examples/README.javademos.

Note, Java is still experimental (principally because of the limited API
that we have at this time) so this configuration effort was not release
critical at all, but I decided to do it anyway while the required
new configuration for our other interfaces was fresh in my mind.

The only other interface not configured with the new approach at this time
is perl, but I am going to leave that strictly to Rafael because the current
version of the perl interface to PLplot is incomplete, and Rafael has
tentative plans to change it over to PDL in any case.  All drivers
(configured both dynamically and statically) are also now configured with
the new scheme. So there should be no further major additions to the current
configuration scheme until substantially after the release (and only then if
Rafael finishes with perl or somebody donates a new interface or driver).

The only other configuration news is that Vince has recently tried the new
configuration scheme on the cygwin platform.  It got all the way through the
compilation stage, but failed at the link stage because I had forgotten an
autoconf macro that is important for cygwin linking according to the
autobook. So we are now on the second iteration there.

We still have an important need for testing of the new configuration scheme
on solaris with tcl/tk, but reports on any other Unix platforms (e.g., MAC
OS X, HPUX, IRIX, AIX, additional OSF1, and additional Linux) would be most
appreciated as well.

We still also have an important need to get the -dev tk problem solved.
(tcl/tk cannot seem to find the scripts in $prefix/lib/plplot-5.1.0/tcl under
these circumstances although there are no problems in other circumstances.)
Is there any plplot tcl guru here who is willing to take this on?

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Re: [Plplot-general] Fw: Obtain Co-ordiantes

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

On Monday 16 December 2002 13:53, Rayal wrote:
> Hi,
>
> I am using Plplot5.1.0 for Tcl/Tk 8.4 on Windows NT. I am trying to plo=
t
> real time data using plplot. My requirement is, when an User clicks on =
the
> plot, I should be able to show (x, y) values of that point ?
>
> Does anybody have an idea how this can be done using tcl-tk and plplot
> library?

Have you checked the "x01c -locate" c example?

Joao
>
> Thanks.
>
> -Rayal

[Plplot-devel] How this can be achived ?

[Piyush L. <pi...@da...>]

Hi,

I am using Plplot 5.1.0 and tcl/tk 8.4 on Windows NT. I am working on a =
project
that requires real time data plotting. My requirement is that the plot =
should be
a strip chart. All the new points should be plot on the right hand side =
with
graph sliding to left, making room for new points. The User can view the =
full
plot using the scroll bars.

When we create the Plplotwin object first we need to specify the =
viewport and
then window. In this we specify the boundary of the graph to be plotted, =
and
there by restricting the size of the plot to be plotted .

Is there any way by which we can eliminate the need of the upper limit =
of the
boundary ( xmax, ymax ) ? Is than any work around which help me to make
continuos plot ?

Does anybody has any idea how this can be done in plplot.?

Thanks for any help.

Piyush L.