plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] build broken

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

On Sat, 31 Aug 2002, Geoffrey Furnish wrote:

> I'm too far behind in my email to know who's been working on such
> things of late.  Does anyone recognize their fingerprint on this
> woopsie?

Mine....;-)

Static drivers don't work at the moment, but I am waiting to fix that until
you (and also Joao) have had a chance to evaluate my new linking scheme for
dynamic drivers which is working well at the moment.  Once we have reached
consensus there, then the changes to make static drivers work should be
straightforward.

The history for the new linking scheme started when I was able to analyze
why we were having troubles with making the xwin, tk, and tkwin (Vince's new
tk driver) into dynamic drivers. Essentially, the problem was caused because
our libraries depended on (directly called functions in) xwin.c and tkwin.c,
while, of course, those dynamic drivers in turn depended on our libraries.
My solution for this Gordian knot was the same as Alexander's.  I split
everything up!  All the tcl and tk interface stuff is now split off from
libplplot into its own library libplplottcltk[d].  Also, my first solution
was all the common functions in xwin.c and tkwin.c (i.e., all those routines
called both by routines in libplplottcltk as well as the the drivers
themselves) were split off from those drivers and put into libplplottcltk.
This solution for the first time gave us working dynamic drivers for xwin,
tk, and tkwin.

However, Joao had objections to using libplplottcltk as simply a grab bag
for these common functions and wanted to reserve libplplottcltk strictly for
interface functions. On the whole, I agree with this goal, but I also did
not want to return to the bad old days where libraries depended explicitly
on functions in driver code making dynamic linking of certain drivers
impossible. Maurice, was kind enough to find a technical solution to this
dilemma; he reunited xwin.c and used an escape function approach for the
parts of xwin.c that were called by routines in libplplottcltk[d].  Thus,
those routines simply call the plplot core and never directly reference
xwin.c which neatly solves the linking issue.  A different solution
(suggested by Vince) for simplifying libplplottcltk was taken for the tkwin
case where everything associated with tkwin was put into the tkwin dynamic
library.  Thus, tkwind_drv.so now contains

Plplotter_Init.o plplotter.o tkwin_common.o tkwin.o


So the current status is that no library depends explicitly on functions in
drivers.  This allows all our drivers to be dynamic which satisfies my
concerns. Furthermore, libplplottcltk has now been
simplified down so that it contains only

tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o  tclMain.o  tkMain.o

I believe this simplification will satisfy most of Joao's concerns, but we
haven't heard his comments yet on the present scheme, and there may be more
that can be done.

Once we reach consensus on what objects go in which libraries, then the next
straightforward step is to get the static drivers to work under Linux.

After that (October at the earliest due to my time constraints), I would
like to make everything work cross-platform, and I have already anticipated
some of the issues there by making the current linking scheme completely
hierarchical under Linux.  That is when we have a chain of library
dependencies so that libw depends on libx depends on liby depends on libz,
the linking step for libw only links in libx, the linking step for libx only
links in liby and the linking step for liby only links in libz. Another way
of saying this is only explicit dependencies are taken into account when
linking and not further dependencies in the chain of libraries. This
hierarchical linking scheme works well under Linux, and it should make it
easier to go cross-platform according to the libtool documentation.

Alan

[Plplot-devel] build broken

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

I did a fresh checkout tonight, first time in a while.

configured with nothing special...:

command:        ../configure --prefix=/home/furnish/xenon
--disable-f77 --disable-cxx --with-double
system:         Linux-2.4.18-3smp
prefix:         /home/furnish/xenon
CC:             gcc -c          -O  
LDC:            gcc    
INCS:            -I. -I/home/furnish/xenon/include
LIBS:            -L/home/furnish/xenon/lib -litk3.2 -ltk8.3 -litcl3.2
-ltcl8.3 -L/usr/X11R6/lib -lX11 -lgd -lpng -ljpeg -lz -ldl -lm
LIB_TAG:        d
devices:         plmeta null xterm tek4010 tek4010f tek4107 tek4107f
mskermit conex vlt versaterm dg300 png jpeg ps psc xfig ljii hp7470
hp7580 lj_hpgl ljiip imp xwin tk pbm pstex

Available device drivers
static:          plmeta null tek dg300 gd ps xfig ljii hpgl ljiip
impress tk pbm pstex  xwin
dynamic:

with_shlib:     yes             with_double:    yes
with_debug:     no              with_opt:       yes
with_warn:      no              with_profile:   no
with_gcc:       yes             with_rpath:     yes

enable_xwin:    yes             enable_tcl:     yes
enable_tk:      yes             enable_itcl:    yes
enable_cxx:     no              enable_python:  no
enable_f77:     no              enable_java:    no
enable_octave:  no              enable_gnome:   no
enable_tkwin:   no

ran make, and got:

[furnish@dhcp-814-13 tmp]$ make
gcc -c          -O    -I. -I/home/furnish/xenon/include -MD -MF
.d.pdfutils -MP -c pdfutils.c -o pdfutils.o
[...]
cd shared; \
gcc -shared -fPIC -o ../libplplottcltkd.so.5.1.0 \
-Wl,-soname -Wl,libplplottcltkd.so.5 \
tclAPI.o Pltk_Init.o tcpip.o plframe.o plr.o xwin.o tclMain.o
tkMain.o  -L.. -lplplotd -ltclmatrixd \
 -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 libplplottcltkd.so.5.1.0 libplplottcltkd.so.5
ln -sf libplplottcltkd.so.5 libplplottcltkd.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. -lplplotd -o plrender \
         -Wl,-rpath -Wl,/home/furnish/devel/plplot/tmp
./libplplotd.so: undefined reference to `Tcl_DeleteInterp'
./libplplotd.so: undefined reference to `gdImageColorAllocate'
./libplplotd.so: undefined reference to `gdImageColorDeallocate'
./libplplotd.so: undefined reference to `Tcl_Init'
./libplplotd.so: undefined reference to `Tcl_GetOpenFile'
./libplplotd.so: undefined reference to `Tcl_DoOneEvent'
./libplplotd.so: undefined reference to `pls_auto_path'
./libplplotd.so: undefined reference to `plWait_Until'
./libplplotd.so: undefined reference to `gdImageDestroy'
./libplplotd.so: undefined reference to `pl_PacketSend'
./libplplotd.so: undefined reference to `plD_dispatch_init_xw'
./libplplotd.so: undefined reference to `Tcl_CreateInterp'
./libplplotd.so: undefined reference to `gdImagePalettePixel'
./libplplotd.so: undefined reference to `gdImageLine'
./libplplotd.so: undefined reference to `gdImagePng'
./libplplotd.so: undefined reference to `gdImageJpeg'
./libplplotd.so: undefined reference to `Tcl_SetVar'
./libplplotd.so: undefined reference to `Tcl_GetVar'
./libplplotd.so: undefined reference to `Tk_Init'
./libplplotd.so: undefined reference to `Tcl_AppendResult'
./libplplotd.so: undefined reference to `gdImageCreate'
./libplplotd.so: undefined reference to `Tcl_ExprBoolean'
./libplplotd.so: undefined reference to `Tcl_CreateCommand'
./libplplotd.so: undefined reference to `gdImageFilledPolygon'
./libplplotd.so: undefined reference to `Tcl_SetVar2'
./libplplotd.so: undefined reference to `Tcl_VarEval'
collect2: ld returned 1 exit status
make: *** [plrender] Error 1


So, it looks like, for some reason, linking plrender is droping the
-ltcl -ltk -lgd, and all that.

I'm too far behind in my email to know who's been working on such
things of late.  Does anyone recognize their fingerprint on this
woopsie? 

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

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

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

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?

Frankly, I don't know specifically what to do, and would be hunting at
random.  I agree that "surely Perl can handle this", but I never use
Windows anymore, and have never even once run a perl script on
Windows. 

The reason for my long silence is partly massive overload on my day
job, and partly that I have just moved out of Silicon Valley, and
relocated to Austin, Tx.  Back to the old stomping grounds.

Anyway, my computer books (perl included) haven't yet been seen since
the move...

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

Re: [Plplot-devel] problems with python bindings under RH7.3

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

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

Re: [Plplot-devel] problems with python bindings under RH7.3

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

Alan W. Irwin writes:
 > Thanks, Gary for that suggestion.  That certainly works for python-2 (i.e.,
 > I get identical test results) so I have committed it.
 > 
 > Maurice, will you please test this out for python-1.5 to see if there are
 > any remaining problems in that case?

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)


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

Re: [Plplot-devel] problems with python bindings under RH7.3

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

Thanks, Gary for that suggestion.  That certainly works for python-2 (i.e.,
I get identical test results) so I have committed it.

Maurice, will you please test this out for python-1.5 to see if there are
any remaining problems in that case?

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, 20 Aug 2002, Gary Bishop wrote:

> I'm super busy with the start of the semester and all but I'll look at
> it if I get a chance. A quick glance at the abstract.h leads me to
> believe that the macros:
>
> #define PySequence_Fast_GET_ITEM PySequence_GetItem
> #define PySequence_Size PySequence_Length
>
> might just do the job.
> gb
>

Re: [Plplot-devel] problems with python bindings under RH7.3

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

Thanks, Maurice, for investigating the python1.5 possibility further.

Gary, do you think it would be straightforward to get plplotcmodule.i
working for python-1.5 or do you think we should just forget about
python-1.5 support and only support python-2?

From your previous messages, I notice you have gotten plplot to work for
RedHat.  Was that for their python2 variant?

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, 20 Aug 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > On Mon, 19 Aug 2002, Maurice LeBrun wrote:
>  > > where "python" for RH7.3 is python1.5.  Is python1.5 no longer supported?
>  >
>  > We should support it for now, and thanks very much for testing that support
>  > (which I cannot do on my Debian system which is fully converted to python 2).
>  >
>  > Before, I found python2 was not reliable in RH7.2 so I used python1.5 in
>  > that case. [...]
>
> OK, I fixed sysloc.in so that I could configure with:
>
> PYTHON_INC_DIR=/usr/include/python1.5 ./configure --enable-python
>
> and get the correct Numeric arrayobject.h file.  But still no go:
>
> trinity$ python ./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: /home/mjl/dev/plplot/plpy/tmp/plplotcmodule.so: undefined symbol:
> PySequence_Fast_GET_ITEM
>
> Turns out plplotcmodule.i relies on some things present in 2.x but not in 1.5,
> such as this macro define and the PySequence_Size() call.  The macro define
> could probably just be replicated here but dunno what to do about
> PySequence_Size().  Grep for these in python's abstract.h file for more info.
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>

Re: [Plplot-devel] problems with python bindings under RH7.3

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

Alan W. Irwin writes:
 > On Mon, 19 Aug 2002, Maurice LeBrun wrote:
 > > where "python" for RH7.3 is python1.5.  Is python1.5 no longer supported?
 > 
 > We should support it for now, and thanks very much for testing that support
 > (which I cannot do on my Debian system which is fully converted to python 2).
 > 
 > Before, I found python2 was not reliable in RH7.2 so I used python1.5 in
 > that case. [...]

OK, I fixed sysloc.in so that I could configure with:

PYTHON_INC_DIR=/usr/include/python1.5 ./configure --enable-python

and get the correct Numeric arrayobject.h file.  But still no go:

trinity$ python ./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: /home/mjl/dev/plplot/plpy/tmp/plplotcmodule.so: undefined symbol:
PySequence_Fast_GET_ITEM

Turns out plplotcmodule.i relies on some things present in 2.x but not in 1.5,
such as this macro define and the PySequence_Size() call.  The macro define
could probably just be replicated here but dunno what to do about
PySequence_Size().  Grep for these in python's abstract.h file for more info.

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

[Plplot-devel] Numeric version for RH 7.3

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

If you use python 1.5, then the traditional python-numeric rpm (see
http://prdownloads.sf.net/numpy/python-numpy-15.3-1.i386.rpm) should be fine
I think.  At least that approach worked well for RH 7.2.

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: Mon, 19 Aug 2002 04:04:02 -0700
From: Maurice LeBrun <ml...@us...>
To: plp...@li...
Subject: [Plplot-cvs] CVS update notice (plplot/cf)

Update of /cvsroot/plplot/plplot/cf
In directory usw-pr-cvs1:/tmp/cvs-serv7424

Modified Files:
	sysloc.in
Log Message:
Added python2.2 to list, needed for RH7.3.  Note a Numeric RPM isn't available
so you have to build/install one from the tarball.



-------------------------------------------------------
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-cvs mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-cvs

[Plplot-devel] plplot_widgetmodule.c changes and plsxwin command restored

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

Maurice, thanks for your changes to plplot_widgetmodule.c so that it uses
the new escape function way of accessing xwin driver functions.  I also just
restored the plsxwin command to the python plplot API.  Olof, note that both
of these changes must be updated from CVS in order for the pyqt GUI (e.g.,
the CVS version of prova.py) to work now.  Please test your own version of
the pyqt GUI to make sure everything is fine.

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: Mon, 19 Aug 2002 03:15:00 -0700
From: Maurice LeBrun <ml...@us...>
To: plp...@li...
Subject: [Plplot-cvs] CVS update notice (plplot/bindings/python)

Update of /cvsroot/plplot/plplot/bindings/python
In directory usw-pr-cvs1:/tmp/cvs-serv28303

Modified Files:
	plplot_widgetmodule.c
Log Message:
Eliminated the plD_open_xw() call in favor of the same logic used by plframe.c
to partially initialize the x driver.



-------------------------------------------------------
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-cvs mailing list
Plp...@li...
https://lists.sourceforge.net/lists/listinfo/plplot-cvs

Re: [Plplot-devel] problems with python bindings under RH7.3

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

Maurice, it is possible with enough hacking around you could get python2
to work properly for RedHat, but I don't trust it since I could not make
it work in RH 7.2 even though I spent a lot of effort.

Therefore, could you undo that symlink and try the default python (1.5)
command with my setup.py.in change?  Hopefully, that will solve all the
1.5 problems, but if not, I am willing to help until they are solved.

Alan

On Mon, 19 Aug 2002, Maurice LeBrun wrote:

> Maurice LeBrun writes:
>  > [python1.5 vs python2.2 problems]
>
> BTW a symlink from /usr/bin/python2.2 to ~/bin/python took care of all of
> these problems.  Probably RedHat will go with python == python2.2 starting
> with their 8.0 release, but for now the symlink solution works fine.  So
> if we decide python1.5 is no longer supported, that's ok with me.
>
> Then the only serious problem is:
>
>  > 3. Tried to run the demos, and it failed.  From the tmp dir:
>  > ...
>  >
>  > trinity$ python2 ./pythondemos.py
>  > Traceback (most recent call 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)
>
> p.s. I did configure with --enable-dyndrivers.
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>
>
> -------------------------------------------------------
> 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] problems with python bindings under RH7.3

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

On Mon, 19 Aug 2002, Maurice LeBrun wrote:

> Just a FYI.  I decided to try once again to get the python bindings to work on
> my RH7.3 machines.  First I built & installed the latest swig, making sure it
> came first in my path, and then that part was traversed correctly.

Good!


> However
> more problems:
>
> 1. During the make I get:
>
> python setup.py build --force --build-temp="./" --build-lib="./" --flat
> Traceback (innermost last):
>   File "setup.py", line 45, in ?
>     libs_list = libs.split(" ")
> AttributeError: 'string' object has no attribute 'split'
> make: *** [plplotcmodule.so] Error 1
>
> where "python" for RH7.3 is python1.5.  Is python1.5 no longer supported?

We should support it for now, and thanks very much for testing that support
(which I cannot do on my Debian system which is fully converted to python 2).

Before, I found python2 was not reliable in RH7.2 so I used python1.5 in
that case. If you look at plplot/rpm/plplot_redhat7.2.spec, you will see I
did the following there:

PY_VERSION=`python -c 'import sys ; print sys.version[0:3]'`
export PYTHON_INC_DIR=/usr/include/python${PY_VERSION}/
echo PYTHON_INC_DIR=${PYTHON_INC_DIR}
export PYTHON_MOD_DIR=/usr/lib/python${PY_VERSION}/
export PYTHON_CFG_DIR=${PYTHON_MOD_DIR}/config
export PYTHON_NUM_DIR=${PYTHON_INC_DIR}/Numeric/
export PYTHON_MACH_DIR=${PYTHON_MOD_DIR}/site-packages
export PYTHON_DIR=${PYTHON_MACH_DIR}
./configure ...

I would stick with python-1.5 until RedHat are confident enough of python-2
to call the associated command "python" rather than "python2".

To solve the above and other split problems, I have just committed
a revised setup.py.in to cvs which replaces the python 2.x method, e.g.,

incs_list = incs.split(" ")

with the python 1.5 (and python 2.x) string function

incs_list = string.split(incs," ")

Please give that a try, and I hope that weeds out all python-2 only constructs
that have crept in since plplot-5.1.0.

Alan

Re: [Plplot-devel] problems with python bindings under RH7.3

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

Maurice LeBrun writes:
 > [python1.5 vs python2.2 problems]

BTW a symlink from /usr/bin/python2.2 to ~/bin/python took care of all of
these problems.  Probably RedHat will go with python == python2.2 starting
with their 8.0 release, but for now the symlink solution works fine.  So
if we decide python1.5 is no longer supported, that's ok with me.

Then the only serious problem is:

 > 3. Tried to run the demos, and it failed.  From the tmp dir:
 > ...
 > 
 > trinity$ python2 ./pythondemos.py 
 > Traceback (most recent call 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)

p.s. I did configure with --enable-dyndrivers.

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

[Plplot-devel] problems with python bindings under RH7.3

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

Just a FYI.  I decided to try once again to get the python bindings to work on
my RH7.3 machines.  First I built & installed the latest swig, making sure it
came first in my path, and then that part was traversed correctly.  However
more problems:

1. During the make I get:

python setup.py build --force --build-temp="./" --build-lib="./" --flat
Traceback (innermost last):
  File "setup.py", line 45, in ?
    libs_list = libs.split(" ")
AttributeError: 'string' object has no attribute 'split'
make: *** [plplotcmodule.so] Error 1

where "python" for RH7.3 is python1.5.  Is python1.5 no longer supported?

2. I added the necessary search path for python2.2 to the config files.
The python for python2.2 under RH7.3 is called "python2".  I also found
I had to build & install Numeric from tarball (no RPM is available), so
I did so.  Everything configured fine at that point, but the make died
at the same place as #1 because the make uses "python" rather than
"python2".  So, I entered this command by hand, typed "make" again,
and everything finally was built.

3. Tried to run the demos, and it failed.  From the tmp dir:

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: /home/mjl/dev/plplot/plpy/tmp/plplotcmodule.so: undefined symbol:
PySequence_Size

So maybe again it was a python vs python2 problem.  Trying again:

trinity$ python2 ./pythondemos.py 
Traceback (most recent call 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)

Any ideas?

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

[Plplot-devel] One more bug killed

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

I just wanted to publically thank Andrew for fixing the colour map changing
bug in the png and jpeg devices (along with all the other upgrades he did to
the gd driver). As I understand the fix, this was done by decoupling the
previous one-to-one correspondence between the PLplot colour map and the
libgd colour map.  Any changes to the PLplot colour maps are now reflected
as additions to the libgd colour map rather than a replacement of the
previous libgd colour map values.  This allows the PLplot colour maps to
change without clobbering the colours of previous plotting done with
a different colour map.

Thanks, Andrew!

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: java examples status (was Re: [Plplot-devel] x16.java ready for testing)

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

On Thu, 15 Aug 2002, Maurice LeBrun wrote:
> If anyone else has work on this stuff pending, let me know asap so
> we don't duplicate efforts.

Nothing pending here.  Thanks very much for your java interface efforts.

Alan

java examples status (was Re: [Plplot-devel] x16.java ready for testing)

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

Alan W. Irwin writes:
 > Here is what I see as the remaining ToDo list for java:
 > 
 > (1) Implement all the API demanded by the examples.  This affects x08.java
 > (pls.scmap1l), x16.java (pls.shade [only partially completed] and pls.shades),
 > and x18.java (pls.poly3 and pls.poin3).

Done with the first.  I'd like to take a whack at the other two as well.

 > (2) Cleanups: Drop redundant dimensions from pls.line and pls.poin that I
 > have discussed before.  You have also mentioned in
 > plplot/bindings/java/README.javaAPI: "[Update, 1/18/02: The plcont wrappers
 > do the 2-d lifetime management stuff right.  Other 2-d functions (using
 > jobjectarrays) should be retrofitted, and certainly new wrappers involving
 > 2-d data args should be modelled after the plcont memory management style.]"
 > Does this still need to be done?

This too.  If anyone else has work on this stuff pending, let me know asap so
we don't duplicate efforts.

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

[Plplot-devel] OpenVMS port of plplot 5.1.0

[<jf....@la...>]

Hi all,

I have successfully port plplot 5.1.0 on OpenVMS.

I have just add 3 files:
build.vms
sys/vms/plconfig.h
sys/vms/pldevs.h


How can I submit these files for a proper inclusion into the standard pac=
kage ?


Cheers,

Jean-Fran=E7ois

Re: [Plplot-devel] prescription for loading tkwin driver?

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

Here is the revised wish recipe that works for me in plplot/tmp

wish
% lappend auto_path [pwd]
/usr/lib/tcl8.3 /usr/lib /usr/lib/tk8.3 /home/software/plplot_cvs/HEAD/plplot_working5/tmp
% package require Plplotter
5.1.0
% source runAllDemos.tcl

I can click any example button in the GUI that comes up, and the appropriate
example is plotted (with the correct black background so the defaults
are working right without having to explicitly source anything).

I have just changed examples/tk/README.tkdemos accordingly.

Note that the plplot/tmp pkgIndex.tcl has been revised so that

set file [file join $dir drivers tkwind_drv[info sharedlibextension]]

for both instances.

If I go to the installed examples directory, it is a different story.

cd /usr/local/plplot/lib/plplot5.1.0/examples/tk
wish
% lappend auto_path /usr/local/plplot/lib/plplot5.1.0
/usr/lib/tcl8.3 /usr/lib /usr/lib/tk8.3 /usr/local/plplot/lib/plplot5.1.0
% package require Plplotter
Can't find a usable plplot.tcl in the following directories:
    /usr/lib/plplot5.1.0/tcl /usr/lib/plplot5.1.0/tcl /lib/plplot5.1.0/tcl
/usr/library /library /plplot5.1.0/tcl/library /plplot5.1.0/tcl/library



This probably means that plplot wasn't installed properly.

If I do the same thing with wish_private, where wish_private is a symlink
to fool tcl into looking in the /usr/local/plplot tree, i.e.,

ls -l /usr/local/plplot/bin/wish_private
lrwxrwxrwx    1 software software       13 Aug  6 12:28 /usr/local/plplot/bin/wish_private -> /usr/bin/wish*

then:

wish_private
% lappend auto_path /usr/local/plplot/lib/plplot5.1.0
/usr/lib/tcl8.3 /usr/lib /usr/local/plplot/lib /usr/lib/tk8.3 /usr/local/plplot/lib/plplot5.1.0
% package require Plplotter
5.1.0
% source runAllDemos.tcl
% invalid command name "x03"

That last error message was generated when I clicked the 3rd example button
on the GUI that came up.

BTW, I followed Vince's instructions and for this test I put pkgIndex.tcl
into /usr/local/plplot/lib/plplot5.1.0  (not the tcl subdirectory).  For
that version I had

grep tkwin /usr/local/plplot/lib/plplot5.1.0/pkgIndex.tcl
        set file [file join $dir ../ libtkwind[info sharedlibextension]]
	set file [file join $dir ../ libtkwind[info sharedlibextension]]

and of course the symlink:

ls -l /usr/local/plplot/lib/libtkwind.so
lrwxrwxrwx    1 software software       55 Aug  6 12:14 /usr/local/plplot/lib/libtkwind.so -> /usr/local/plplot/lib/plplot5.1.0/drivers/tkwind_drv.so*

Time for me to bow out of these tcl install problems associated with wish,
and let the experts take over.  Maurice, can you verify the problem above
and would you be willing to follow up?  I would ask Vince, but he doesn't
have access to a Linux box.

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] prescription for loading tkwin driver?

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

Alan W. Irwin writes:
 > On Tue, 6 Aug 2002, Alan W. Irwin wrote:
 > 
 > > I was able to do ./x01c -dev xwin with the installed libraries a few days
 > > ago, but I also confirm it no longer works now with -dev xwin.
 > >
 > > I have looked at your changes and see nothing to disagree with.  So it is a
 > > puzzle.  But I believe I can figure out what is going on since that error
 > > message comes from just one part of the plplot core code.
 > 
 > Actually, I now see the problem.  In an earlier set of changes you removed
 > all dependencies for the installed drivers and that messed up the use of $<
 > later on in the rule so, e.g., xwin.o wasn't being put into xwin_drv.so
 > (which caused something of a problem...;-)) I have just reinstated the first
 > dependency shared/xwin$O, etc., for each of the drivers in CVS, and now
 > ./x01c -dev xwin, -dev tkwin, and -dev tk works fine for the installed
 > drivers (so long as your PATH points to $prefix/bin).
 > 
 > In general, I would like to keep dependencies in, if it doesn't mess up the
 > RH version of make.  Maurice, I don't think it was these first dependencies
 > that were giving you trouble with RH make. However, please test this out,
 > and if you are still having trouble we can do it without the dependency by
 > replacing $< in the rule by the appropriate value.

Whoops.  Thanks for catching that one.. so much for being fast & loose. :)
I'll give the Plplotter package another try.

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

Re: [Plplot-devel] prescription for loading tkwin driver?

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

On Tue, 6 Aug 2002, Alan W. Irwin wrote:

> I was able to do ./x01c -dev xwin with the installed libraries a few days
> ago, but I also confirm it no longer works now with -dev xwin.
>
> I have looked at your changes and see nothing to disagree with.  So it is a
> puzzle.  But I believe I can figure out what is going on since that error
> message comes from just one part of the plplot core code.

Actually, I now see the problem.  In an earlier set of changes you removed
all dependencies for the installed drivers and that messed up the use of $<
later on in the rule so, e.g., xwin.o wasn't being put into xwin_drv.so
(which caused something of a problem...;-)) I have just reinstated the first
dependency shared/xwin$O, etc., for each of the drivers in CVS, and now
./x01c -dev xwin, -dev tkwin, and -dev tk works fine for the installed
drivers (so long as your PATH points to $prefix/bin).

In general, I would like to keep dependencies in, if it doesn't mess up the
RH version of make.  Maurice, I don't think it was these first dependencies
that were giving you trouble with RH make. However, please test this out,
and if you are still having trouble we can do it without the dependency by
replacing $< in the rule by the appropriate value.

I haven't done any deep testing, yet, but I believe the installed version
should now be good to go.

Alan

Re: [Plplot-devel] prescription for loading tkwin driver?

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

I was pleased to see you have gotten package require Plplotter to work.  It's
amazing how the machine couldn't figure out what I meant by autopath....;-)

I was able to do ./x01c -dev xwin with the installed libraries a few days
ago, but I also confirm it no longer works now with -dev xwin.

I have looked at your changes and see nothing to disagree with.  So it is a
puzzle.  But I believe I can figure out what is going on since that error
message comes from just one part of the plplot core code.

As far as the static drivers are concerned, the xwin, tk, and tkwin drivers
should all be merged into libplplottcltk (I think that is already taken care
of with the present configuration), and the rest merged into libplplot (I
suspect the current configuration would merge all drivers there which would
be a mistake).  The linking of libplplottcltk and libplplot would also have
to be changed to accommodate the special libraries required by the various
drivers.  So it shouldn't be that bad (he says...;-)), and I encourage you
to give it a try.

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, 6 Aug 2002, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > I will do a complete test of everything tomorrow to verify your changes work
>  > here.  Also, I will try once again to get auto_path to work (this time
>  > spelled correctly! Last time I was using autopath which is why nothing
>  > worked.)   Basically I am thinking of
>  >
>  > lappend auto_path /usr/local/plplot/lib/plplot5.1.0/tcl
>  >
>  > the symlink I discussed before, and a modified pkgIndex.tcl
>  >
>  > to see if the wish recipe can be simplified when plplot is installed.
>
> My first attempt went pretty straightforward.  Note everything I'm talking
> about here is in the install tree.
>
> First, pkgIndex.tcl wasn't being installed, so I copied it to
> $prefix/lib/plplot5.1.0/ by hand.
>
> pkgIndex.tcl then needed updating.. I changed the first few lines to:
>
> if {$tcl_platform(platform) == "unix"} {
>     if {[info exists tcl_platform(debug)]} {
>         set file [file join $dir drivers tkwind_drv[info sharedlibextension]]
>     } else {
>         set file [file join $dir drivers tkwin_drv[info sharedlibextension]]
>     }
>
> Then I did:
>
> wish
> % package require Plplotter
> 5.1.0
>
> so all appears well so far.  Note I didn't have to add anything to auto_path
> b/c I have wish installed in the same local dir tree as plplot.
>
> But then unfortunately in trying to run the demos I get:
>
> % source runAllDemos.tcl
> Unable to locate dispatch table initialization function for driver:
> tkwin_drv.so.
> Segmentation fault
>
> So then I tried:
>
> $ cd $prefix/lib/plplot5.1.0/examples/c
> $ make x01c
> $ x01c -dev xwin
> Plplot library version: 5.1.0
> Unable to locate dispatch table initialization function for driver:
> xwin_drv.so.
> Segmentation fault
>
> Also using the tk driver segfaults as well.  So all is not well in
> install-land.
>
> I have no idea what's going on, and didn't write the dynload code (in fact
> have been using static drivers up to now), so that's probably all I will
> do on this for now.  I may take a look at getting the static drivers
> working again (broken pretty badly now from the looks of it).
>
> --
> Maurice LeBrun    mj...@ga...
> Research Organization for Information Science and Technology of Japan (RIST)
>

Re: [Plplot-devel] prescription for loading tkwin driver?

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

Alan W. Irwin writes:
 > I will do a complete test of everything tomorrow to verify your changes work
 > here.  Also, I will try once again to get auto_path to work (this time
 > spelled correctly! Last time I was using autopath which is why nothing
 > worked.)   Basically I am thinking of
 > 
 > lappend auto_path /usr/local/plplot/lib/plplot5.1.0/tcl
 > 
 > the symlink I discussed before, and a modified pkgIndex.tcl
 > 
 > to see if the wish recipe can be simplified when plplot is installed.

My first attempt went pretty straightforward.  Note everything I'm talking
about here is in the install tree.

First, pkgIndex.tcl wasn't being installed, so I copied it to
$prefix/lib/plplot5.1.0/ by hand.

pkgIndex.tcl then needed updating.. I changed the first few lines to:

if {$tcl_platform(platform) == "unix"} {
    if {[info exists tcl_platform(debug)]} {
        set file [file join $dir drivers tkwind_drv[info sharedlibextension]]
    } else {
        set file [file join $dir drivers tkwin_drv[info sharedlibextension]]
    }

Then I did:

wish
% package require Plplotter
5.1.0

so all appears well so far.  Note I didn't have to add anything to auto_path
b/c I have wish installed in the same local dir tree as plplot.

But then unfortunately in trying to run the demos I get:

% source runAllDemos.tcl
Unable to locate dispatch table initialization function for driver:
tkwin_drv.so.
Segmentation fault

So then I tried:

$ cd $prefix/lib/plplot5.1.0/examples/c
$ make x01c
$ x01c -dev xwin
Plplot library version: 5.1.0
Unable to locate dispatch table initialization function for driver:
xwin_drv.so.
Segmentation fault

Also using the tk driver segfaults as well.  So all is not well in
install-land.

I have no idea what's going on, and didn't write the dynload code (in fact
have been using static drivers up to now), so that's probably all I will
do on this for now.  I may take a look at getting the static drivers
working again (broken pretty badly now from the looks of it).

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

Re: [Plplot-devel] prescription for loading tkwin driver?

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

You don't want:

lappend auto_path /usr/local/plplot/lib/plplot5.1.0/tcl

but

lappend auto_path /usr/local/plplot/lib/plplot5.1.0

sorry I wasn't more explicit.

-- Vince

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

Nevermind (was Re: [Plplot-devel] does the java support work?)

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

glurb.  Didn't sufficiently RTFM.

Maurice LeBrun writes:
 > BTW this is using the jdk1.3.1_03 RPM from Sun for RH 7.3, so it should work.
 > 
 > Maurice LeBrun writes:
 >  > A vanilla configure --enable-java & make gives the following error
 >  > on my machine:
 >  > 
 >  > javac -d java config.java
 >  > javac -d java PLStream.java
 >  > PLStream.java:403: cannot resolve symbol
 >  > symbol  : class config  
 >  > location: package core
 >  >         System.loadLibrary( plplot.core.config.libname );
 >  >                                        ^
 >  > 1 error
 >  > make: *** [java/plplot/core/PLStream.class] Error 1

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