plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] plimage

[<jca...@in...>]

On Tuesday 27 November 2001 00:21, Alessandro Mirone wrote:
| Hi Joao,
=2E..
| I send you in attachement a small patch containing mainly
| a comment for the call to plimage and  commenting out
| some unused variables that were defined in plstrm.h but used only
| by moveimage function.

I applied your patch. Thanks for keeping plplot clean.

However, I removed, instead of commenting, the extra statements. Only=20
latter I realized that your intention was to really comment them, for=20
a possible posterior utilization with moveimage(). Sorry for that.

I have meanwhile partially fixed your FillPolygonCmd() acceleration=20
(just for one plot direction of the rectangle drawing).
The speed improvements are small, ~4% in x16c.c, measured repeating=20
100 times the first plshades() call. It accelerates 459 in a total of=20
5418 possible rectangles.=20
I think that it deserves further improvements, considering all 4=20
possibles cases of rectangle direction drawing, but meanwhile I will=20
keep it out of xwin.c (until you find yourself motivated to improve=20
it :).

=2E..

| P.S.
|   is there a way to really desactivate tcl/tk  and compiling
| plplot on a system not having tcl/tk ?( my feeling
|  is that even if you desactivate tcl/tk you need the tcl/tk libs)

Do you mean that your system does not have tcl/tk and that=20
nonetheless tcl/tk was detected by configure?
Or do you have tcl/tk and you just dont want plplot support for it?

In the former case, please supply a more detailed bug report=20
(including "configure" output).
In the later case, try to configure with "--disable-tcl --disable-tk".

Thanks,
Joao

Re: [Plplot-devel] x20c.c

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

On Tue, 27 Nov 2001, Alan W. Irwin wrote:

> (png
> format also has the truecolour alternative, but we must avoid that because
> plplot would not be able to work with it.) I have just found that the
> combination of pnmquant and pnmtopng does produce the colour-pallete style
> png format.  Now I have done little coding yet, but from the documentation
> it looks like the colour pallette is accessible using the libgd library so
> that for the cost of ~15 extra lines of code in x20c we can demonstrate
> processing a colour image.  With a few lines of commentary in x20c.c we can
> also advise all our Linux users how to use the netpbm utilities to transform
> *any* of their favorite colour images into a png image with colour palette
> that the ~15 lines of libgd-related code in x20c.c could understand.

Correction: I have just discovered the gdImageTrueColorToPalette function in
libgd which translates an image from truecolour to palette.  So strike my
comments about netpbm.  Everything we need to process colour png images of
any type is already in libgd.

Alan

Re: [Plplot-devel] x20c.c

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

On Tue, 27 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote:
>
> | Thus, Andrew, I like your suggestion for using png format for our
> | standard input format
>
> Do we have a standard [image] input format? That is another issue. As
> Andrew said, there are two issues here: x20c.c and libplplot.

Indeed there are two issues.  But I think you are misunderstanding me here.
My whole e-mail including the sentence you quoted was focussed on improving
the x20c.c demo by using png images as the input and had nothing to do with
libplplot.

> If we are willing to have image reading/convertion in libplplot, than
> we must start thinking on what we want, why, implement it, and than
> recode x20c.c to use and *demonstrate* the new libplplot capabilities.

That's one possibility.  Another possibility is to leave plplot strictly al=
one
and simply enhance x20c.c to make a nice looking demo that the majority
of our users can relate to and immediately adapt for their own needs.

>
> But I don't think that plplot should have such image capabilities, as
> there are enought good quality libraries for that purpose. Instead,
> the user will write his program, read the image in whatever format he
> desires, using the method or library he desires, transformate it in
> whatever way he desires, and then call plimage() to draw it.

I think I agree with you on the libplplot issue. There are all sorts of
excellent arguments for keeping it narrowly focussed on a plotting API
without adding extra features that aren't directly related to plotting.  So
let us forget libplot and concentrate on the x20c.c issue from now on.

>
> x20c.c uses a fast and crude way of reading an image, with the
> purpose of demonstrate a libplplot API. "lena" is generaly available
> as jpeg. As I *didn't* want to use libgd to read jpeg, I converted it
> to ppm, which is simple to read.

I acknowledge your approach seems to work now (from your subsequent e-mail
although you haven't checked it in so I cannot see for myself, yet), and
also it does have the great advantage of simplicity.  Nevertheless, in my
view it is too limited an approach. IMHO, part of the point of demos is to
allow our users to relate plplot with other work. Thus, I would profoundly
disagree with the notion that no special libraries are allowed to be used b=
y
our examples other than libplplot and friends.  Here with x20c we have an
outstanding chance to do something really interesting so let us take
advantage of the opportunity rather than limiting ourselves.

To be specific, right now you limit the x20c demonstration to false colour
(using default cmap1) and gray-scale images.  With the png approach we can
have the demonstration of actual colour images (i.e., scanned photographs o=
r
whatever).  Now in order to work with colour images in plplot you do need
the appropriate colour pallette defined for cmap1, but the png format, for
example, does allow for up to 256 different colours in a pallette.  (png
format also has the truecolour alternative, but we must avoid that because
plplot would not be able to work with it.) I have just found that the
combination of pnmquant and pnmtopng does produce the colour-pallete style
png format.  Now I have done little coding yet, but from the documentation
it looks like the colour pallette is accessible using the libgd library so
that for the cost of ~15 extra lines of code in x20c we can demonstrate
processing a colour image.  With a few lines of commentary in x20c.c we can
also advise all our Linux users how to use the netpbm utilities to transfor=
m
*any* of their favorite colour images into a png image with colour palette
that the ~15 lines of libgd-related code in x20c.c could understand.

Joao, instead of more discussion about this *before the fact*, let me try t=
o
implement colour images for x20c in the way I have outlined as a basis for
further discussion. If I am successful with the code, and there are no othe=
r
nasty issues that arise, I hope to convince you that a colour picture of
Lena will look better....;-) I have already found a colour version of this
test image at http://www.dcs.gla.ac.uk/~wpc/gmm3/web/lena.jpg.

Andrew, I assume you haven't yet had a chance to implement a libgd-based
image reading routine for x20c so I am just going to go ahead on my own.

Alan

Re: [Plplot-devel] x20c.c

[<jca...@in...>]

On Tuesday 27 November 2001 16:20, you wrote:
| On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote:
| | My motivation here is to have a good-looking demo.  Obviously
| | something is not correct about the current method of reading in
| | lena.pgm
|
| Thus, lets correct it.

Done. Just a "char *" to an "unsigned char*" change. I will commit it=20
this night.

Joao

Re: [Plplot-devel] dyn-drivers linking -- again!

[<jca...@in...>]

On Tuesday 27 November 2001 00:38, Alan W. Irwin wrote:
| On Tue, 27 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:
| > But I still have one doubt. Currently, $driverlibs in dyndrv.in
| > uses all libs that libplplot is linked with; I think that the
| > dyn-drivers only needs to be linked with libplplot itself, (as
| > libplplot itself is linked with tclmatrix, etc, and as such the
| > dyn-driver will find them).
=2E..
| > Can you check it out, Alan?
|
| Yes, java with -dev png works fine with current CVS (see above).

Sorry, I meant, using=20

=09driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)

Well, I followed your recipe and build java (jdk-1.1.8). Python=20
demos, Java demos and Octave demos all run OK with the png device (as=20
well as other fiole devices), using only the above driverslibs.

Joao

Re: [Plplot-devel] x20c.c

[<jca...@in...>]

On Tuesday 27 November 2001 07:35, Alan W. Irwin wrote:
| My motivation here is to have a good-looking demo.  Obviously
| something is not correct about the current method of reading in
| lena.pgm

Thus, lets correct it.

| since the other parts of the demo show that plimage works
| well, and if I look at lena.pgm directly with kview, that is one
| heck of a good-looking image....;-) Probably, one could fix up the
| current pgm input, but I don't see much point to this reincarnation
| of the libpgm library if we can satisfy the valid cross-platform
| concerns that you and Joao have expressed another way.

There is no such reincarnation of libpgm in x20c.c. libpgm has=20
certainly much more functionalities than just reading "lena".

| Thus, Andrew, I like your suggestion for using png format for our
| standard input format

Do we have a standard [image] input format? That is another issue. As=20
Andrew said, there are two issues here: x20c.c and libplplot.

As libplplot currently has no API entries to reading/convert images,=20
x20c.c uses a fast and crude way of reading an image, with the=20
purpose of demonstrate a libplplot API. "lena" is generaly available=20
as jpeg. As I *didn't* want to use libgd to read jpeg, I converted it=20
to ppm, which is simple to read.

If we are willing to have image reading/convertion in libplplot, than=20
we must start thinking on what we want, why, implement it, and than=20
recode x20c.c to use and *demonstrate* the new libplplot capabilities.

But I don't think that plplot should have such image capabilities, as=20
there are enought good quality libraries for that purpose. Instead,=20
the user will write his program, read the image in whatever format he=20
desires, using the method or library he desires, transformate it in=20
whatever way he desires, and then call plimage() to draw it.

Thus, I think that one must correct the x20c.c *demo*, and eventually=20
discuss the image operations to add to plplot.

Joao

| and using libgd to read it since both are
| cross-platform. Also as you point out, on Linux the user can
| convert anything to png format using the netpbm package.  I have
| already used that package in the following way: anytopnm < lena.pgm
| | pnmtopng > lena.png. The high-quality result was
| indistinguishable from the original even at high magnification.
| Thus, I would like to concentrate now on getting proper input of
| png images for x20c.c so we can have a good-looking result.
|
| Now the big question for Andrew: would you be willing to programme
| png input to x20c.c using libgd (version 2)?  I am willing to do
| this myself starting tomorrow using libgd version 2.0.1 that is on
| my Debian woody system, but it might take me a while and with your
| C skills it might be trivial for you to do. Even if you provide
| just the bare bones of the png reading programme, it would help me
| get a much quicker start.  Let me know what you decide.
|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
| On Tue, 27 Nov 2001, Andrew Roach wrote:
| > At 12:09 AM 27/11/01 +0000, Jo=E3o Cardoso wrote:
| > >On Monday 26 November 2001 20:43, Alan W. Irwin wrote:
| > >| I have a suggestion.  Why not add a function to this demo to
| > >| input various image formats and extract the information
| > >| required by plimage? Right now, there is rudimentary support
| > >| for reading ppm images from x20c.c, and I suggest replacing
| > >| this with the appropriate calls to libpbm, libpgm, libpnm, or
| > >| libppm.
| > >
| > >I have no strong objections to that, except that x20c will
| > > depend on libraries that may not be available on some other
| > > systems. In the first place, unix is not linux, plplot runs
| > > also on Macs and MSWindows, and the purpose of a demo is just
| > > showing a capability. That's the reason why I spend some time
| > > coding the reading of the image, instead of just calling a
| > > library. (After all it looks like that I have objections ;-)
| >
| > I am inclined to agree with Joao here with regards to the
| > concerns of having those libraries available on other systems. I
| > confess that have never looked to see if libpbm etc... are
| > available for DJGPP, thought I expect they would be in some form.
| > What would prove more difficult is evoking external image
| > converter programs on other platforms. I /personally/ think it is
| > perhaps best left as is, with the image command just rendering a
| > user-supplied bitmap, and leaving the supply/generation of that
| > bitmap up to the user.
| >
| > However, if we do want to have INTERNAL loading of bitmaps (not
| > just user-provided ones) there are some other things to consider.
| >
| > With respect to linking to libpbm etc... and letting them do the
| > image reading, and then using external conversion programs to
| > change the format into pbms etc... that almost SETS the preferred
| > image format to the pbm family. Why pick that format over any
| > others ? It is a very easy one to read in a demo like X20c, but
| > isn't necessarily the most flexible or acceptable image format
| > out there. There is almost zero use on platforms outside on
| > unix/linux. We could just as easily (and perhaps more logically),
| > link to libgd, libjpeg, & libpng then read either JPEGs and/or
| > PNG images as the "raw format" supported by plplot, using
| > external image converters to convert other formats (ie the pbm
| > family) to PNGs. In some respect, especially for DOS, windows,
| > and MACs, PNGs have more use, flexibility, and acceptance than
| > the pbm family. Just a thought...
| >
| > - Andrew
| >
| >
| >
| >
| > _______________________________________________
| > Plplot-devel mailing list
| > Plp...@li...
| > https://lists.sourceforge.net/lists/listinfo/plplot-devel
|
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] x20c.c

[Andrew R. <ar...@ge...>]

>My motivation here is to have a good-looking demo.  Obviously something is
>not correct about the current method of reading in lena.pgm since the other

I believe the problem is caused by the fact that the image uses all 256
greyscales, whereas the PNG driver is using CMAP1's 240 greyslots (the
other 16 being taken by CMAP0) and at present no translation is being made.
So basically everything is moved "down" by 16 indices, and the top 16 are
lost. That is an issue that will probably have to be resolved even with GD,
although gd quite possibly has in-built functions that would simplify the
task.

>Now the big question for Andrew: would you be willing to programme png input
>to x20c.c using libgd (version 2)?  I am willing to do this myself starting
>tomorrow using libgd version 2.0.1 that is on my Debian woody system, but it
>might take me a while and with your C skills it might be trivial for you to
>do. Even if you provide just the bare bones of the png reading programme, it
>would help me get a much quicker start.  Let me know what you decide.

I will have a loot at it tomorrow and see what is involved and get back to
you. 
- Andrew

Re: [Plplot-devel] x20c.c

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

My motivation here is to have a good-looking demo.  Obviously something is
not correct about the current method of reading in lena.pgm since the other
parts of the demo show that plimage works well, and if I look at lena.pgm
directly with kview, that is one heck of a good-looking image....;-)
Probably, one could fix up the current pgm input, but I don't see much poin=
t
to this reincarnation of the libpgm library if we can satisfy the valid
cross-platform concerns that you and Joao have expressed another way.

Thus, Andrew, I like your suggestion for using png format for our standard
input format and using libgd to read it since both are cross-platform. Also
as you point out, on Linux the user can convert anything to png format usin=
g
the netpbm package.  I have already used that package in the following way:
anytopnm < lena.pgm | pnmtopng > lena.png. The high-quality result was
indistinguishable from the original even at high magnification. Thus, I
would like to concentrate now on getting proper input of png images for
x20c.c so we can have a good-looking result.

Now the big question for Andrew: would you be willing to programme png inpu=
t
to x20c.c using libgd (version 2)?  I am willing to do this myself starting
tomorrow using libgd version 2.0.1 that is on my Debian woody system, but i=
t
might take me a while and with your C skills it might be trivial for you to
do. Even if you provide just the bare bones of the png reading programme, i=
t
would help me get a much quicker start.  Let me know what you decide.

Alan

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

Linux-powered astrophysics
__________________________

On Tue, 27 Nov 2001, Andrew Roach wrote:

> At 12:09 AM 27/11/01 +0000, Jo=E3o Cardoso wrote:
> >On Monday 26 November 2001 20:43, Alan W. Irwin wrote:
> >| I have a suggestion.  Why not add a function to this demo to input
> >| various image formats and extract the information required by
> >| plimage? Right now, there is rudimentary support for reading ppm
> >| images from x20c.c, and I suggest replacing this with the
> >| appropriate calls to libpbm, libpgm, libpnm, or libppm.
> >
> >I have no strong objections to that, except that x20c will depend on
> >libraries that may not be available on some other systems. In the
> >first place, unix is not linux, plplot runs also on Macs and
> >MSWindows, and the purpose of a demo is just showing a capability.
> >That's the reason why I spend some time coding the reading of the
> >image, instead of just calling a library. (After all it looks like
> >that I have objections ;-)
>
> I am inclined to agree with Joao here with regards to the concerns of
> having those libraries available on other systems. I confess that have
> never looked to see if libpbm etc... are available for DJGPP, thought I
> expect they would be in some form. What would prove more difficult is
> evoking external image converter programs on other platforms. I
> /personally/ think it is perhaps best left as is, with the image command
> just rendering a user-supplied bitmap, and leaving the supply/generation =
of
> that bitmap up to the user.
>
> However, if we do want to have INTERNAL loading of bitmaps (not just
> user-provided ones) there are some other things to consider.
>
> With respect to linking to libpbm etc... and letting them do the image
> reading, and then using external conversion programs to change the format
> into pbms etc... that almost SETS the preferred image format to the pbm
> family. Why pick that format over any others ? It is a very easy one to
> read in a demo like X20c, but isn't necessarily the most flexible or
> acceptable image format out there. There is almost zero use on platforms
> outside on unix/linux. We could just as easily (and perhaps more
> logically), link to libgd, libjpeg, & libpng then read either JPEGs and/o=
r
> PNG images as the "raw format" supported by plplot, using external image
> converters to convert other formats (ie the pbm family) to PNGs. In some
> respect, especially for DOS, windows, and MACs, PNGs have more use,
> flexibility, and acceptance than the pbm family. Just a thought...
>
> - Andrew
>
>
>
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] x20c.c

[Andrew R. <ar...@ge...>]

At 12:09 AM 27/11/01 +0000, Jo=E3o Cardoso wrote:
>On Monday 26 November 2001 20:43, Alan W. Irwin wrote:
>| I have a suggestion.  Why not add a function to this demo to input
>| various image formats and extract the information required by
>| plimage? Right now, there is rudimentary support for reading ppm
>| images from x20c.c, and I suggest replacing this with the
>| appropriate calls to libpbm, libpgm, libpnm, or libppm.
>
>I have no strong objections to that, except that x20c will depend on=20
>libraries that may not be available on some other systems. In the=20
>first place, unix is not linux, plplot runs also on Macs and=20
>MSWindows, and the purpose of a demo is just showing a capability.=20
>That's the reason why I spend some time coding the reading of the=20
>image, instead of just calling a library. (After all it looks like=20
>that I have objections ;-)

I am inclined to agree with Joao here with regards to the concerns of
having those libraries available on other systems. I confess that have
never looked to see if libpbm etc... are available for DJGPP, thought I
expect they would be in some form. What would prove more difficult is
evoking external image converter programs on other platforms. I
/personally/ think it is perhaps best left as is, with the image command
just rendering a user-supplied bitmap, and leaving the supply/generation of
that bitmap up to the user.

However, if we do want to have INTERNAL loading of bitmaps (not just
user-provided ones) there are some other things to consider.=20

With respect to linking to libpbm etc... and letting them do the image
reading, and then using external conversion programs to change the format
into pbms etc... that almost SETS the preferred image format to the pbm
family. Why pick that format over any others ? It is a very easy one to
read in a demo like X20c, but isn't necessarily the most flexible or
acceptable image format out there. There is almost zero use on platforms
outside on unix/linux. We could just as easily (and perhaps more
logically), link to libgd, libjpeg, & libpng then read either JPEGs and/or
PNG images as the "raw format" supported by plplot, using external image
converters to convert other formats (ie the pbm family) to PNGs. In some
respect, especially for DOS, windows, and MACs, PNGs have more use,
flexibility, and acceptance than the pbm family. Just a thought...

- Andrew

Re: [Plplot-devel] dyn-drivers linking -- again!

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

On Tue, 27 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> But I still have one doubt. Currently, $driverlibs in dyndrv.in uses
> all libs that libplplot is linked with; I think that the dyn-drivers
> only needs to be linked with libplplot itself, (as libplplot itself
> is linked with tclmatrix, etc, and as such the dyn-driver will find
> them).

Probably....;-)

>
> But this dyn-driver linking stuff has given so many problems (sorry
> Geoffrey :) that I'm afraid to change it again.

I am afraid also....;-)

> I would
> like to try the java bindings but somehow I forgot the environment
> variables receipe (CLASSPATH=3Djava and LD_LIBRARY_PATH=3D`pwd` ? "make
> jdemos" runs OK).

Here is the java recipe I use:

#point to whatever jdk you have
setenv JAVA_HOME /home/software/java/jdk1.2.2/
#so you have access to java and javac
setenv PATH $PATH":$JAVA_HOME/bin"
setenv CLASSPATH java
setenv LD_LIBRARY_PATH .                         #to run in plplot/tmp

Then run configure with appropriate options (and make sure it finds java).
make; cd tmp; make jdemos
java plplot.examples.x01 -dev png -o test.png

That last command works fine for me with the current CVS.  Note on newer
jdk's you can use the command "java plplot/examples/x01 ...", instead, but
that doesn't work on old jdk versions so I stick with the dots.

>
> Can you check it out, Alan?

Yes, java with -dev png works fine with current CVS (see above).

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] plimage

[<jca...@in...>]

On Tuesday 27 November 2001 00:21, Alessandro Mirone wrote:
| Hi Joao,
|
|  at home I could finally work on plplot ( at home I have tk8.3, not
| just tk8.0)
| So I got the newest cvs.
|  You have done really a good job reordering my patch
| that was coming from an intense trial and error process
|
| I send you in attachement a small patch containing mainly
| a comment for the call to plimage and  commenting out
| some unused variables that were defined in plstrm.h but used only
| by moveimage function.
|
| I liked very much x20c, expecially the beautiful girl ;-).

Yes, "lena" is a well know image benchmark. But... plplot still draws=20
it very badly... poor Lena. Try "xv lena.pgm" or "display" or=20
whatsoever. Colormap problems? A bad (my) understanding of the ppm=20
image format?

Have you noticed the comment "if" in xwin.c, FillPolygonCmd()?

 /* Fill polygons */

  if( 0 /* buggy!, try e.g. x12c. Disable it */ && pls->dev_npts =3D=3D=20

It was part of your patch (without the "0 /* buggy" part). Shall I=20
remove it, or do you intend to correct it?

Do you anticipate to need all the PLESC_IMAGEOPS operations?

I will apply your patches latter.

|
| all the best
|
|                   Alessandro
|
| P.S.
|   is there a way to really desactivate tcl/tk  and compiling
| plplot on a system not having tcl/tk ?( my feeling
|  is that even if you desactivate tcl/tk you need the tcl/tk libs)

For the list, I quote:

even if I=20
=A0./configure --with-double --enable-tcl=3Dno =A0
I get

gcc =A0 plrender.o -L. -lplplotd =A0-o plrender \
=A0 =A0 =A0 =A0 -L -ltk -L/usr/X11R6/lib -lX11 -ltcl8.0 -ltk8.0 -lvga -ld=
l -lm
-lg2c -Wl,-rpath -Wl,/scisoft/users/mirone/tmp/PLPLOT/plplot/tmp
=2E/libplplotd.so: undefined reference to `pls_auto_path'
=2E/libplplotd.so: undefined reference to `plTclCmd'
=2E/libplplotd.so: undefined reference to `Matrix_Init'=20


where I had to add by hand -ltcl8.0 -ltk8.0 =A0otherwise compiling
complains.
Maybe it's cause of tk =A0installation on the=20
machines at work.
=A0Is'nt there a way to really cut off tcl/tk if one wants to compile
without it?

end of quote

Thanks, Joao

Re: [Plplot-devel] x20c.c

[<jca...@in...>]

On Monday 26 November 2001 20:43, Alan W. Irwin wrote:
| I have a suggestion.  Why not add a function to this demo to input
| various image formats and extract the information required by
| plimage? Right now, there is rudimentary support for reading ppm
| images from x20c.c, and I suggest replacing this with the
| appropriate calls to libpbm, libpgm, libpnm, or libppm.

I have no strong objections to that, except that x20c will depend on=20
libraries that may not be available on some other systems. In the=20
first place, unix is not linux, plplot runs also on Macs and=20
MSWindows, and the purpose of a demo is just showing a capability.=20
That's the reason why I spend some time coding the reading of the=20
image, instead of just calling a library. (After all it looks like=20
that I have objections ;-)

Joao

|  I have
| never used those free libraries directly, but the license (as
| interpreted by the Debian copyright notice) puts no restrictions
| whatsoever on our code, and it is the library used by the huge
| number of linux image converters.  Also, use of these libraries
| (which come with the netpbm package, see
| http://netpbm.sourceforge.net/netpbm.html#lbAM) means you have
| direct read access to pbm, pgm, pnm, or ppm images from your C
| code. Furthermore, from the C code you could invoke the the free
| image converter with the system command that was appropriate (e.g.,
| pngtopnm, jpegtopnm, tifftopnm, pstopnm, and many more or indeed
| anytopnm which is a superset of all of them) to convert a given
| format to pnm which can then be read into x20c using libpnm.
|
| If there are no objections to this way to have access to many
| different image formats, I am willing to give this a try.
|
| 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
| __________________________
|
|
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] dyn-drivers linking -- again!

[<jca...@in...>]

On Monday 26 November 2001 09:36, Alan W. Irwin wrote:
| I solved the problem.... Explanation below.
|
| On Mon, 26 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:
| > As far as I know, all dynamic drivers are treated the same way,
| > as the procedure to load them is the same.
| > Thus, the problem is with python dynamic loading, not the gd
| > driver (that works for other bindings/programs). It must be one
| > of those environment variables that we like so much... I make no
| > idea.
| >
| > The problem is with python needing to load both libplplotd.so and
| > drivers/gd.drv. It founds the last, but not the first.
|
| I think the actual linking model is more complicated than that
| (which may be the source of the trouble).  I am no expert on
| linking so you may have to correct my mental model, but here is
| what I think is happening with the linking.  When plmodule.so is
| created, it is linked (not dynamically linked) to libplplot.  So at
| run time when you import pl, plmodule.so is dynamically linked by
| python.  When you execute say plinit from python, plmodule.so
| translates it to the appropriate libplplot call which is found and
| run-time linked by the ordinary loader (just the way you get access
| to any other library such as libc from plmodule.so).  libplplot
| itself then may make a dynamic load of the device drivers.  This
| whole complicated mechanism works fine for the psc device, but
| somehow it is falling apart for the png device.
|
| I therefore carefully went over the Makefile and found that
| $(driverlibs) was missing from the drivers/gd.drv build line as
| well as the equivalent ntk.drv and gnome.drv lines.

That was my fault, yes.
I always think in terms of compiled programs, not interpreted ones.=20
Compiled programs are linked against libplplot, and thus the drivers=20
"inherit" it. For the same to happen with python (java, etc), python=20
itself should be linked with libplplot, what is a nonsense.

But I still have one doubt. Currently, $driverlibs in dyndrv.in uses=20
all libs that libplplot is linked with; I think that the dyn-drivers=20
only needs to be linked with libplplot itself, (as libplplot itself=20
is linked with tclmatrix, etc, and as such the dyn-driver will find=20
them).

But this dyn-driver linking stuff has given so many problems (sorry=20
Geoffrey :) that I'm afraid to change it again. Anyhow, using=20

    driverlibs :=3D -L. -l$(PLLIB_NAME)$(LIB_TAG)

only on dyndrv.in enables "./pythondemos.py -dev png -fam -o po.png"=20
to run OK. In Octave I also was able to use the png driver. I would=20
like to try the java bindings but somehow I forgot the environment=20
variables receipe (CLASSPATH=3Djava and LD_LIBRARY_PATH=3D`pwd` ? "make=20
jdemos" runs OK).=20

Can you check it out, Alan? I hate (OK, dislike, I'm a latin, you=20
know, I have strong feelings :) to do/have un-necessary things in the=20
code/Makefiles.

Joao

[Plplot-devel] ntk driver

[<jca...@in...>]

On Monday 26 November 2001 09:36, Alan W. Irwin wrote:
| BTW, Joao.  This was my first chance to try out your ntk driver. I
| am really glad you made that effort.  It gives some nice-looking
| results for the 46 pages generated by pythondemos.py in an
| amazingly short amount of time.

humm, you are very kind, but I think that the ntk driver is *too*=20
slow (e.g., filling). It was a first naive implementation, and I=20
didn't even *finish* it.

But I think ntk can have a very promising future, regarding=20
inter-platform capability. The tk driver uses the xwin driver, and as=20
such can't run on Macs or Windows; the ntk driver is pure tcl/tk, and=20
as such beneficts from tcl/tk multiple platform capabilities.

Joao

[Plplot-devel] plimage

[Alessandro M. <ale...@wa...>]

Hi Joao,
  
 at home I could finally work on plplot ( at home I have tk8.3, not just
tk8.0)
So I got the newest cvs.
 You have done really a good job reordering my patch
that was coming from an intense trial and error process 

I send you in attachement a small patch containing mainly
a comment for the call to plimage and  commenting out
some unused variables that were defined in plstrm.h but used only
by moveimage function.

I liked very much x20c, expecially the beautiful girl ;-).

all the best

                  Alessandro

P.S.
  is there a way to really desactivate tcl/tk  and compiling
plplot on a system not having tcl/tk ?( my feeling
 is that even if you desactivate tcl/tk you need the tcl/tk libs)

[Plplot-devel] x20c.c

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

I have a suggestion.  Why not add a function to this demo to input various
image formats and extract the information required by plimage? Right now,
there is rudimentary support for reading ppm images from x20c.c, and I
suggest replacing this with the appropriate calls to libpbm, libpgm, libpnm,
or libppm.  I have never used those free libraries directly, but the license
(as interpreted by the Debian copyright notice) puts no restrictions
whatsoever on our code, and it is the library used by the huge number of
linux image converters.  Also, use of these libraries (which come with the
netpbm package, see http://netpbm.sourceforge.net/netpbm.html#lbAM) means
you have direct read access to pbm, pgm, pnm, or ppm images from your C
code. Furthermore, from the C code you could invoke the the free image
converter with the system command that was appropriate (e.g., pngtopnm,
jpegtopnm, tifftopnm, pstopnm, and many more or indeed anytopnm which is a
superset of all of them) to convert a given format to pnm which can then be
read into x20c using libpnm.

If there are no objections to this way to have access to many different
image formats, I am willing to give this 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
__________________________

[Plplot-devel] Solaris xwin.c fix

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

Since we use mostly plplot-general and plplot-devel, it was only by accident
that I spotted an xwin suggestion on our forum which appears to be useful.
Please look at
http://sourceforge.net/forum/forum.php?thread_id=105137&forum_id=8607 where
it is stated a change to our XCreateWindow call solves all solaris problems
for this particular user.

I don't know anything about the syntax of XCreateWindow, but it appears the
guy used the X default depth and visual rather than the values known to
plplot (which I assume were either not set correctly at all and the Linux X
server could overcome this or had values which were legal for the Linux X
server but somehow illegal for the solaris X server).  I applied this change
(after correcting his typo where he substituted ev for dev), and it works
fine on my Linux box. Thus, I have gone ahead and put it in CVS as a basis
for further discussion.

BTW, as part of the xwin testing for this I had a look at x20c.  That is
a most interesting and useful capability to add to plplot.

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] Problem solved! (was png driver no longer works for python)

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

I solved the problem.... Explanation below.

On Mon, 26 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

> As far as I know, all dynamic drivers are treated the same way, as
> the procedure to load them is the same.
> Thus, the problem is with python dynamic loading, not the gd driver
> (that works for other bindings/programs). It must be one of those
> environment variables that we like so much... I make no idea.
>
> The problem is with python needing to load both libplplotd.so and
> drivers/gd.drv. It founds the last, but not the first.

I think the actual linking model is more complicated than that (which may b=
e
the source of the trouble).  I am no expert on linking so you may have to
correct my mental model, but here is what I think is happening with the
linking.  When plmodule.so is created, it is linked (not dynamically linked=
)
to libplplot.  So at run time when you import pl, plmodule.so is dynamicall=
y
linked by python.  When you execute say plinit from python, plmodule.so
translates it to the appropriate libplplot call which is found and run-time
linked by the ordinary loader (just the way you get access to any other
library such as libc from plmodule.so).  libplplot itself then may make a
dynamic load of the device drivers.  This whole complicated mechanism works
fine for the psc device, but somehow it is falling apart for the png device=
=2E

I therefore carefully went over the Makefile and found that $(driverlibs)
was missing from the drivers/gd.drv build line as well as the equivalent
ntk.drv and gnome.drv lines.  I have subsequently fixed those 3 missing
$(driverlibs) problems, and committed to cvs.

I now find

=2E/pythondemos.py -dev png -fam -fflen 2 -o test.png

works great as does

=2E/pythondemos.py -dev ntk.

=2E/pythondemos.py -dev gnome crashes immediately, but as I recall Rafael w=
as
never satisfied with the gnome driver so I am not going to worry about that
until he brings it into more final state.  (But please take note, Rafael,
of this problem for future reference.)

I believe these fixes work for the png and ntk cases because $(driverlibs)
includes a reference to libplplot which is supplying the missing symbol.  I
have no idea how this missing symbol was supplied before for (say) x01c or
other C examples that worked in the past with the dynamic gd driver.  I
guess with this odd mixture of dynamic loading and ordinary run-time loadin=
g
that occurs for python, library order matters for resolving symbols more
than for the C front-end case where libplplot is run-time loaded right away=
=2E

BTW, Joao.  This was my first chance to try out your ntk driver. I am reall=
y
glad you made that effort.  It gives some nice-looking results for the 46
pages generated by pythondemos.py in an amazingly short amount of time.

Alan

Re: [Plplot-devel] png driver no longer works for python

[<jca...@in...>]

On Saturday 24 November 2001 18:39, Alan W. Irwin wrote:
| I just fixed the configuration issue so python should be a little
| easier to work with.
|
| I just tried the case with static drivers and pythondemos.py -dev
| png works. Thus, the only combination I know of that doesn't work
| is dynamic drivers + pythondemos.py -dev png.  I hope Joao is able
| to confirm this now for python=3D1.5.2 using double.

Yes:

jcard@rick:~/tmp/plplot/tmp > ./pythondemos.py -dev png -o po.png
Device not loaded!
tag=3Dpng, drvidx=3D4
Trying to load gd.drv on ./drivers/gd.drv
Trying to load at /usr/local/test/lib/drivers/gd.drv
Unable to load driver: gd.drv.
Reason: /usr/local/test/lib/drivers/gd.drv: cannot open shared object=20
file: No such file or directory <------------------------------------
Segmentation fault

The driver is not found at all. Setting PYTHONDIR=3D`pwd`

(by the way, where are all those variables (java also variables)=20
documented?)

jcard@rick:~/tmp/plplot/tmp > export=20
PYTHONDIR=3D/usr/local/test/python/=20
jcard@rick:~/tmp/plplot/tmp > ./pythondemos.py -dev jpeg -o po.jpeg
Device not loaded!
tag=3Djpeg, drvidx=3D4
Trying to load gd.drv on ./drivers/gd.drv
Trying to load at /usr/local/test/lib/drivers/gd.drv
Unable to load driver: gd.drv.
Reason: /usr/local/test/lib/drivers/gd.drv: undefined symbol: <-----
plP_setpxl
Segmentation fault

So, now the driver is loaded, but plP_setpxl is not found.
But the symbol is defined in libplplot.so:

jcard@rick:~/tmp/plplot/tmp > nm -p libplplotd.so | fgrep plP_setpxl
00019910 T plP_setpxl

| Presuming that will be confirmed, I think the key question is how
| is the dynamic ps driver treated differently than the dynamic gd
| driver?

As far as I know, all dynamic drivers are treated the same way, as=20
the procedure to load them is the same.
Thus, the problem is with python dynamic loading, not the gd driver=20
(that works for other bindings/programs). It must be one of those=20
environment variables that we like so much... I make no idea.

The problem is with python needing to load both libplplotd.so and=20
drivers/gd.drv. It founds the last, but not the first.

If I change RTLD_NOW to RTLD_LAZY in plcore.c, the behaviour changes,=20
but the demo still does not run.

No more ideias.

Joao

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

[Plplot-devel] plimage()

[<jca...@in...>]

Hi,

I have cvs commited Alessandro plimage() contribution, as well as a=20
x20c.c demo. Try it with the xwin driver or the file (ps/png...)=20
drivers.

This is a first try, and I hope that with Alessandro help we will be=20
able to fix some problems. Alessandro, please check it, as well as=20
the x20c.c demo.

The call interface is likely to change, as Alessandro contribution=20
used  "PLFLT *M" as the way to pass the image matrix, while PLplot=20
"standard" is "PLFLT **M".

Joao

[Plplot-devel] modified plssub and tcl and python example fixups + test results

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

I have updated plssub as discussed previously here, and I have also made a
number of modifications to the tcl and python examples to get rid of some
bugs and to adjust to the new plssub. For details look at the commit
messages on plplot_cvs.

To follow the tests of current CVS that I did, I suggest you try
./tcldemos.tcl (following directions inside that file) and pythondemos.py
with devices psc, png, xfig, or plmeta.  As previously discussed you will
need to use the static driver to get the png device to work, and to avoid a
segfault you will need to comment out xw09 from pythondemos.py if you are
using python 2.0 or later. (xw09 seems to work fine for python-1.5.)

The tests also reveal a problem with the xfig driver when there is more than
one plot done at once.  In that case the 3rd and 4th examples are missing
some of the lines from the plot. When those plots are done alone (e.g., by
commenting out everything but xw03 from pythondemos.tcl) or if the tests are
filtered through the plmeta device, then plrendered to create an xfig file,
the missing line problem goes away.  I have no clue why there is this
bizarre behaviour, but I have only run into it for the xfig driver.

Other than the dynamic/png, xw09 segfault, and now the new xfig problem I
have discovered, all other results looked good.

I also did some batch testing with plplot-test.sh --flat
--driver=psc,png,plmeta. The colour (see p15.png), legend, and square aspect
ratio problems I have mentioned before for the octave examples continue for
the png driver.  However, the plmeta (when plrendered) and psc octave
results look good without any of the problems that occur for png.  I don't
understand these differences (especially square versus rectangular plots)
unless there is something driver-specific being done in the octave "p"
examples.  As I recall, there are also some octave examples that try to
mimic the x??c examples.  I will try those instead to see whether there
are any problems with png 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
__________________________

Re: [Plplot-devel] May I remove the undocumented page advance from plssub?

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

Alan W. Irwin writes:
 > ...
 > I have taken out the page advance buried in c_plssub, and all the ordinary
 > examples using plssub seem to be fine without it, and it solves the
 > problem of the empty pages.  Does anybody have an objection if
 > I commit that change to CVS?

I personally have no objection.  It may break a small amount existing code,
none of mine tho. :) And it seems more logical your way -- I think I've
noticed this misfeature before but didn't feel like changing it as it doesn't
really affect me..

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] png driver no longer works for python

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

I just fixed the configuration issue so python should be a little easier to
work with.

I just tried the case with static drivers and pythondemos.py -dev png works.
Thus, the only combination I know of that doesn't work is dynamic drivers +
pythondemos.py -dev png.  I hope Joao is able to confirm this now for
python=1.5.2 using double.

Presuming that will be confirmed, I think the key question is how is the
dynamic ps driver treated differently than the dynamic gd driver?

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] png driver no longer works for python

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

On Sat, 24 Nov 2001, [iso-8859-1] Jo=E3o Cardoso wrote:

**Reordered to get the small issues out of the way first:**

> jcard@rick:~/tmp/plplot/tmp > ./pythondemos.py -dev ps -o po.ps
> Device not loaded!
> tag=3Dpsm, drvidx=3D5
> Trying to load ps.drv on ./drivers/ps.drv
> Opened po.ps
> Traceback (innermost last):
>   File "./pythondemos.py", line 23, in ?
>     import xw01
>   File "/home/jcard/tmp/plplot/tmp/xw01.py", line 141, in ?
>     main()
>   File "/home/jcard/tmp/plplot/tmp/xw01.py", line 20, in main
>     plot1(6., 1., 0., 0.)
>   File "/home/jcard/tmp/plplot/tmp/xw01.py", line 63, in plot1
>     plpoin(xs, ys, 9)
> TypeError: Array can not be safely cast to required type
>
> The above message happens for most, but not all, examples.

I believe that is because you didn't configure with double.  Currently
python only works if double is configured. Anyhow, once you have double
configured you should have no problems with the postscript driver and
pythondemos.py.

> There is some configure problems with pyqt. I dont have it installed,
> but it is build anyway! It looks like configure don't check for it.

pyqt_plmodule.c is probably misnamed.  It has some support functions that
are called from the example prova.py+qplplot.py, but those support function=
s
are generic and and don't actually refer to pyqt.  Thus, pyqt_plmodule.c ca=
n
be built regardless of whether pyqt is there or not. It is only the example
prova.py+qplplot.py that imports qt and thus, that is the only place where
it makes a difference whether pyqt is available or not.  If that module is
not available on your system, you just simply get the normal python error
message to that effect when you run the example ./prova.py.

>
> Also, I have problems with "make" after the first sucesseful make,
> i.e., the first make runs OK, but the second and next give the
> following message:
>
> > touch plline.c
> > make
>
> ....
>
> Building Python module.
>
> echo 'pl plmodule.c plmodule2.c -I. -I/usr/include/python1.5
> -I/usr/include/python1.5/Numeric -L.. -L. -lplplot -ltclmatrix
> -ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -Wl,-rpath
> -Wl,/home/jcard/tmp/plplot/tmp' >> python_dynamic/Setup.in
> cd python_dynamic ; make -s -f Makefile.pre.in boot ; make -s ; \
> mv -f plmodule.so ..
> mv: plmodule.so: No such file or directory
> make: *** [plmodule.so] Error 1
>

Yes, that is a minor configuration issue I have not sorted out.  To get
around it rm python_dynamic/Setup before each fresh make after the first.

> On Saturday 24 November 2001 00:32, Alan W. Irwin wrote:
> | With plplot tree freshly updated from CVS, I configure like I
> | normally do, e.g.,
> |
> | ./configure --prefix=3D/usr/local/plplot --with-double
> | --enable-dynamic-drivers --enable-java --enable-gnome > & !
> | configure.out
> |
> | Then from tmp I executed
> | ./pythondemos.py -dev png
> | Unable to load driver: gd.drv.
> | Reason: /usr/local/plplot/lib/drivers/gd.drv: undefined symbol:
> | plP_setpxl Segmentation fault
> |
> | First, why should a test in tmp refer to some previously installed
> | version in /usr/local/plplot?
> | Second, when I removed /usr/local/plplot/* I got a new error
> | message:
> |
> | ./pythondemos.py -dev png -o temp.png
> | Unable to load driver: gd.drv.
> | Reason: /usr/local/plplot/lib/drivers/gd.drv: cannot open shared
> | object file: No such file or directory
> |
> | So somehow /usr/local/plplot is hardcoded in the python case.  With
> | /usr/local/plplot removed, I have no trouble with the png driver
> | for the x01c example, and the psc driver works both for the x01c
> | and pythondemos.py examples.
> |
> | I am virtually positive I checked the png driver before when I was
> | first testing pythondemos.py.  Since then, I have changed to
> | python-2.1 and Joao has made some driver changes so I don't know
> | which is causing the trouble. Joao, can you replicate this problem
> | on your (presumably) python-1.5 system?
>
> Not exactly:
>
> jcard@rick:~/tmp/plplot/tmp > ./pythondemos.py -dev png -o po.png
> Device not loaded!
> tag=3Dpng, drvidx=3D4
> Trying to load gd.drv on ./drivers/gd.drv
> Trying to load at /usr/local/test/lib/drivers/gd.drv
> Unable to load driver: gd.drv.
> Reason: /usr/local/test/lib/drivers/gd.drv: cannot open shared object
> file: No such file or directory
> Segmentation fault

>
> I have plcore modified to print diagnostics while trying to load
> dynamic drivers, thus the more verbose output.
>
> I'm using python-1.5.2.

Once you have changed over to double, pythondemos.py should work fine with
the psc driver.  It is only the png driver where there is a problem as you
confirm above for python-1.5. From your above extra diagonistics it looks
like it cannot find gd.drv first in tmp/drivers.gd.drv then in the install
location.  What is different about the gd.drv setup compared to the ps.drv
setup?

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] png driver no longer works for python

[<jca...@in...>]

On Saturday 24 November 2001 00:32, Alan W. Irwin wrote:
| With plplot tree freshly updated from CVS, I configure like I
| normally do, e.g.,
|
| ./configure --prefix=3D/usr/local/plplot --with-double
| --enable-dynamic-drivers --enable-java --enable-gnome > & !
| configure.out
|
| Then from tmp I executed
| ./pythondemos.py -dev png
| Unable to load driver: gd.drv.
| Reason: /usr/local/plplot/lib/drivers/gd.drv: undefined symbol:
| plP_setpxl Segmentation fault
|
| First, why should a test in tmp refer to some previously installed
| version in /usr/local/plplot?
| Second, when I removed /usr/local/plplot/* I got a new error
| message:
|
| ./pythondemos.py -dev png -o temp.png
| Unable to load driver: gd.drv.
| Reason: /usr/local/plplot/lib/drivers/gd.drv: cannot open shared
| object file: No such file or directory
|
| So somehow /usr/local/plplot is hardcoded in the python case.  With
| /usr/local/plplot removed, I have no trouble with the png driver
| for the x01c example, and the psc driver works both for the x01c
| and pythondemos.py examples.
|
| I am virtually positive I checked the png driver before when I was
| first testing pythondemos.py.  Since then, I have changed to
| python-2.1 and Joao has made some driver changes so I don't know
| which is causing the trouble. Joao, can you replicate this problem
| on your (presumably) python-1.5 system?

Not exactly:

jcard@rick:~/tmp/plplot/tmp > ./pythondemos.py -dev png -o po.png
Device not loaded!
tag=3Dpng, drvidx=3D4
Trying to load gd.drv on ./drivers/gd.drv
Trying to load at /usr/local/test/lib/drivers/gd.drv
Unable to load driver: gd.drv.
Reason: /usr/local/test/lib/drivers/gd.drv: cannot open shared object=20
file: No such file or directory
Segmentation fault

I have plcore modified to print diagnostics while trying to load=20
dynamic drivers, thus the more verbose output.

I'm using python-1.5.2, and most python demos fail:

jcard@rick:~/tmp/plplot/tmp > ./pythondemos.py -dev ps -o po.ps=20
Device not loaded!
tag=3Dpsm, drvidx=3D5
Trying to load ps.drv on ./drivers/ps.drv
Opened po.ps
Traceback (innermost last):
  File "./pythondemos.py", line 23, in ?
    import xw01
  File "/home/jcard/tmp/plplot/tmp/xw01.py", line 141, in ?
    main()
  File "/home/jcard/tmp/plplot/tmp/xw01.py", line 20, in main
    plot1(6., 1., 0., 0.)
  File "/home/jcard/tmp/plplot/tmp/xw01.py", line 63, in plot1
    plpoin(xs, ys, 9)
TypeError: Array can not be safely cast to required type

The above message happens for most, but not all, examples; e.g.,=20
xw06.py works OK. As for you, the C examples work OK:

jcard@rick:~/tmp/plplot/tmp > ./x01c -dev png -o po.png
Plplot library version: 5.0.4
Device not loaded!
tag=3Dpng, drvidx=3D4
Trying to load gd.drv on ./drivers/gd.drv
Opened po.png

So, I don't know what the problem is, as I never used python, and my=20
changes to the driver where only related with dynamic building, never=20
touching the code itself.

There is some configure problems with pyqt. I dont have it installed,=20
but it is build anyway! It looks like configure don't check for it.

Also, I have problems with "make" after the first sucesseful make,=20
i.e., the first make runs OK, but the second and next give the=20
following message:

> touch plline.c
> make

=2E...

Building Python module.
=20
echo 'pl plmodule.c plmodule2.c -I. -I/usr/include/python1.5=20
-I/usr/include/python1.5/Numeric -L.. -L. -lplplot -ltclmatrix=20
-ltk8.3 -ltcl8.3 -L/usr/X11R6/lib -lX11 -ldl -lm -Wl,-rpath=20
-Wl,/home/jcard/tmp/plplot/tmp' >> python_dynamic/Setup.in
cd python_dynamic ; make -s -f Makefile.pre.in boot ; make -s ; \
mv -f plmodule.so ..
mv: plmodule.so: No such file or directory
make: *** [plmodule.so] Error 1

Joao