plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] gd driver and dlopen() flags

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

On Monday 16 September 2002 19:21, Jo=E3o Cardoso wrote:
| On Monday 16 September 2002 18:45, Alan W. Irwin wrote:
| | On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
| | > Hi,
| | >
| | > In the current cvs I can't use the png driver:
=2E..

| [jcard@feup] make x01c && LD_LIBRARY_PATH=3D. ./x01c -dev png -o po.png
| -debug
| make: `x01c' is up to date.
| Plplot library version: 5.1.0
| plLoadDriver: Device not loaded!
| plLoadDriver: tag=3Dpng, drvidx=3D4
| plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
| plLoadDriver: Local dlopen failed because of the following reason:
| ./drivers/gdd_drv.so: undefined symbol: gdImagePalettePixel
| plLoadDriver: Trying to load at
| /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so
| plLoadDriver: Global dlopen failed because of the following reason:
| /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot open
| shared object file: No such file or directory
| Unable to load driver: gdd_drv.so.
| Segmentation fault
|
| [jcard@feup] rpm -q gd
| gd-1.8.4-238
|
| And gdImagePalettePixel() does not exists in the gd library.

I found that gdImagePalettePixel() is really a macro:

#define gdImagePalettePixel(  im, x, y )   (im)->pixels[(y)][(x)]

So, putting it above  gd.c:plD_gd_optimise(), makes the unknown symbol=20
error to disappear, but the seg fault still happens:

[jcard@feup] ./x01c -dev png -o po.png
Plplot library version: 5.1.0
Opened po.png
Segmentation fault
[jcard@feup] ./x01c -dev png -o po.png -debug
Plplot library version: 5.1.0
plLoadDriver: Device not loaded!
plLoadDriver: tag=3Dpng, drvidx=3D4
plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
Opened po.png
Segmentation fault

[jcard@feup] ls -l po.png
-rw-r--r--    1 jcard    users        8192 Sep 16 20:01 po.png

Notice that the file is written to some extent.

Joao

[Plplot-devel] python does not compile in suse-8.0

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

I'm a kind of bug reporter, now :)

Building Python modules.
=20
# Start fresh (--force) each time since previous build may
# be for an installation rather than for present plplot/tmp location.
python setup.py build --force --build-temp=3D"./" --build-lib=3D"./" --fl=
at
running build
running build_ext
building 'plplotcmodule' extension
plplotcmodule.c:627: warning: `PySequence_Fast_GET_ITEM' redefined
/usr/include/python2.2/abstract.h:1004: warning: this is the location of=20
the previous definition
plplotcmodule.c: In function `_wrap_pltr0':
plplotcmodule.c:663: `$1' undeclared (first use in this function)
plplotcmodule.c:663: (Each undeclared identifier is reported only once
plplotcmodule.c:663: for each function it appears in.)
plplotcmodule.c: In function `_wrap_pltr1':
plplotcmodule.c:783: `$1' undeclared (first use in this function)
plplotcmodule.c:783: `$input' undeclared (first use in this function)
plplotcmodule.c: In function `_wrap_pltr2':

=2E.. etc

# rpm -q python
python-2.2-105

Re: [Plplot-devel] gd driver and dlopen() flags

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

On Monday 16 September 2002 18:45, Alan W. Irwin wrote:
| On Mon, 16 Sep 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
| > Hi,
| >
| > In the current cvs I can't use the png driver:
| >
| > [jcard@feup] ./x01c -dev png -o po.png -debug
| > Plplot library version: 5.1.0
| > plLoadDriver: Device not loaded!
| > plLoadDriver: tag=3Dpng, drvidx=3D4
| > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
| > plLoadDriver: Trying to load at
| > /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so
| > Unable to load driver: gdd_drv.so.
| > Reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so:
| > cannot open shared object file: No such file or directory
|
| This misleading error message from the wrong (second) dlerror has
| been annoying me for a while so I just fixed it in CVS.  Could you
| please try this again after cvs update?  That should give you both
| the first and second dlerror error messages with the -debug option
| (and no dlerror error messages if you don't specify -debug).
|
| Once the first dlerror message is output, I suspect you will get an
| error message about no access to a symbol in one of our libraries.=20
| If so, could you try to fix it by setting LD_LIBRARY_PATH to point to
| the directory (./ in this case) where our libraries have been built?
|
| > If I change in plcore.c, line 1855, RTLD_NOW to RTLD_LAZY, it
| > works:
| >
| > [jcard@feup] ./x01c -dev png -o po.png -debug
| > Plplot library version: 5.1.0
| > plLoadDriver: Device not loaded!
| > plLoadDriver: tag=3Dpng, drvidx=3D4
| > plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
| > Opened po.png
| > Segmentation fault
| >
| > Oops... at home it worked (exactly same environement).
| > Nevertheless, now the driver is opened and the output file created
| > and partly filled, so there is some problem here.
|
| I don't need the RTLD_LAZY (or LD_LIBRARY_PATH under Debian), but I
| do confirm the second error you have just found.  Something is now
| wrong with the gd device driver if you don't specify -drvopt text.  I
| will look into it further.
|
| From the Linux dlopen man page at
| http://nodevice.com/sections/ManIndex/man0254.html, I don't see how
| RTLD_LAZY will fix the problem.  It will, however, delay the problem
| until you actually try to use the symbols, and you may have
| encountered the second error (see above) before that happened.  Once
| you re-run with the proper dlerror message and RTLD_NOW, we will know
| more.
|
| Alan

[jcard@feup] make x01c && LD_LIBRARY_PATH=3D. ./x01c -dev png -o po.png=20
-debug
make: `x01c' is up to date.
Plplot library version: 5.1.0
plLoadDriver: Device not loaded!
plLoadDriver: tag=3Dpng, drvidx=3D4
plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
plLoadDriver: Local dlopen failed because of the following reason:
=2E/drivers/gdd_drv.so: undefined symbol: gdImagePalettePixel
plLoadDriver: Trying to load at=20
/usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so
plLoadDriver: Global dlopen failed because of the following reason:
/usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot open=20
shared object file: No such file or directory
Unable to load driver: gdd_drv.so.
Segmentation fault

[jcard@feup] rpm -q gd
gd-1.8.4-238

And gdImagePalettePixel() does not exists in the gd library.

Joao

|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by:ThinkGeek
| Welcome to geek heaven.
| http://thinkgeek.com/sf
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] build broken

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

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

> On Saturday 31 August 2002 13:24, Alan W. Irwin wrote:
> | [...]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].
>
> This is a good thing.
> Can we make also a libplplotf77 library from scstubs.o sfstubs.o?

I hope so.  If I recall correctly, this has long been on Maurice's ToDo lis=
t.

Geoffrey, would you also be willing to go along with splitting out the java
interface stuff from libplplot if I do the work?  Ultimately, I would like
to see all interface API removed from libplplot. I think it just makes
maintenance issues a lot easier to solve if we move toward reserving
libplplot exclusively for fundamental PLplot API.  Ultimately, I guess it
just boils down to the Unix philosophy of splitting everything up into
small specialized entities which communicate well (in this case by the link=
ing
mechanism) rather than attempting an integrated approach.

> |  [...] 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
>
> Good. Of course this implies that the user has to specify the location
> of tkwin_drv.so.
> It's easy to do in the build directory, but might cause problems in the
> installed location--the user must know where it is. From other e-mails
> I understand that the problem was already solved setting 'auto_path' by
> using 'lappend', I just dont know if this is performed automatically or
> if it requires the user to set it up.

I got everything to work well in the build location, but there are still
some Tcl/Tk install issues which I have now forgotten but which I documente=
d
to the list.  I suspect there is a simple solution, but it will need to be
provided by a Tcl Linux expert.

>
> That's fine. The only missing thing is to reunify tkwin_common.c and
> tkwin.c, I believe.

I don't care one way or the other here, and I believe the same is true
for Vince.  So if you want to reunite tkwin, please go ahead.

>
> [...] The other object files in libplplottcltk.* (but tclAPI.o) are
> application dependent, and should, I think, be linked directly with the
> applications they were written for, as they are useless for other
> programs or the user:  Pltk_Init.o is for the tk_win driver (and I
> checked that if removed from libplplottcltk.so and included in
> drivers/tkwin_drv.so the tkwin driver still works), tclMain.o is for
> pltcl, and tkMain.o is for plserver.
> With these changes, libplplottcltk.* would contain only tclAPI.o,
> plframe.o, tcpip.o and plr.o.
>
> These changes would only clarify what is from what, without any
> advantages or disadvantages.

Sounds good to me!  Unfortunately, it is taking me longer than I thought to
finish my current astronomical research project (partly because I have been
sneaking in a lot of work on short plplot projects) so it may be late
October *at the earliest* before I can get to this.  So if you could do it
first, I would much appreciate it.

Alan

Re: [Plplot-devel] gd driver and dlopen() flags

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

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

>
> Hi,
>
> In the current cvs I can't use the png driver:
>
> [jcard@feup] ./x01c -dev png -o po.png -debug
> Plplot library version: 5.1.0
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=3Dpng, drvidx=3D4
> plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
> plLoadDriver: Trying to load at
> /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so
> Unable to load driver: gdd_drv.so.
> Reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot
> open shared object file: No such file or directory

This misleading error message from the wrong (second) dlerror has been
annoying me for a while so I just fixed it in CVS.  Could you please try
this again after cvs update?  That should give you both the first and secon=
d
dlerror error messages with the -debug option (and no dlerror error message=
s
if you don't specify -debug).

Once the first dlerror message is output, I suspect you will get an error
message about no access to a symbol in one of our libraries.  If so, could
you try to fix it by setting LD_LIBRARY_PATH to point to the directory
(./ in this case) where our libraries have been built?


> If I change in plcore.c, line 1855, RTLD_NOW to RTLD_LAZY, it works:
>
> [jcard@feup] ./x01c -dev png -o po.png -debug
> Plplot library version: 5.1.0
> plLoadDriver: Device not loaded!
> plLoadDriver: tag=3Dpng, drvidx=3D4
> plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
> Opened po.png
> Segmentation fault
>
> Oops... at home it worked (exactly same environement). Nevertheless, now
> the driver is opened and the output file created and partly filled, so
> there is some problem here.

I don't need the RTLD_LAZY (or LD_LIBRARY_PATH under Debian), but I do
confirm the second error you have just found.  Something is now wrong with
the gd device driver if you don't specify -drvopt text.  I will look into i=
t
further.

From=20the Linux dlopen man page at
http://nodevice.com/sections/ManIndex/man0254.html, I don't see how
RTLD_LAZY will fix the problem.  It will, however, delay the problem until
you actually try to use the symbols, and you may have encountered the secon=
d
error (see above) before that happened.  Once you re-run with the proper
dlerror message and RTLD_NOW, we will know more.

Alan

Re: [Plplot-devel] build broken

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

On Saturday 31 August 2002 13:24, Alan W. Irwin wrote:
| 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!=20
| All the tcl and tk interface stuff is now split off from libplplot
| into its own library libplplottcltk[d].

This is a good thing.
Can we make also a libplplotf77 library from scstubs.o sfstubs.o?

|  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.

That's fine.

|  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

Good. Of course this implies that the user has to specify the location=20
of tkwin_drv.so.
It's easy to do in the build directory, but might cause problems in the=20
installed location--the user must know where it is. From other e-mails=20
I understand that the problem was already solved setting 'auto_path' by=20
using 'lappend', I just dont know if this is performed automatically or=20
if it requires the user to set it up.

| 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.

That's fine. The only missing thing is to reunify tkwin_common.c and=20
tkwin.c, I believe.

Unfortunately it is not possible to do with the tk driver the same thing=20
that was done with the tkwin one -- put everything that is driver=20
dependent in tk_drv.so. This is because plframe.o, tcpip.o and plr.o=20
are also needed by tkwin.

The other object files in libplplottcltk.* (but tclAPI.o) are=20
application dependent, and should, I think, be linked directly with the=20
applications they were written for, as they are useless for other=20
programs or the user:  Pltk_Init.o is for the tk_win driver (and I=20
checked that if removed from libplplottcltk.so and included in=20
drivers/tkwin_drv.so the tkwin driver still works), tclMain.o is for=20
pltcl, and tkMain.o is for plserver.
With these changes, libplplottcltk.* would contain only tclAPI.o,=20
plframe.o, tcpip.o and plr.o.

These changes would only clarify what is from what, without any=20
advantages or disadvantages.

What do you think of this last proposal?

Joao

| 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
|
|
|
| -------------------------------------------------------
| 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=3Dsourceforge1&refcode1=3Dvs3390
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] gd driver and dlopen() flags

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

Hi,

In the current cvs I can't use the png driver:

[jcard@feup] ./x01c -dev png -o po.png -debug
Plplot library version: 5.1.0
plLoadDriver: Device not loaded!
plLoadDriver: tag=3Dpng, drvidx=3D4
plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
plLoadDriver: Trying to load at=20
/usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so
Unable to load driver: gdd_drv.so.
Reason: /usr/local/lib/plplot5.1.0/data/../drivers/gdd_drv.so: cannot=20
open shared object file: No such file or directory
Segmentation fault

Notice that I'm runing from the build tmp directory, that=20
drivers/gdd_drv.so exists, there is no installed plplot, this also=20
happens with the single precision driver, it does not happens with any=20
other drivers, this happens in a freshly installed suse-8.0.

If I change in plcore.c, line 1855, RTLD_NOW to RTLD_LAZY, it works:

[jcard@feup] ./x01c -dev png -o po.png -debug
Plplot library version: 5.1.0
plLoadDriver: Device not loaded!
plLoadDriver: tag=3Dpng, drvidx=3D4
plLoadDriver: Trying to load gdd_drv.so on ./drivers/gdd_drv.so
Opened po.png
Segmentation fault

Oops... at home it worked (exactly same environement). Nevertheless, now=20
the driver is opened and the output file created and partly filled, so=20
there is some problem here.
Of course using LAZY instead of NOW would fix the problem (and I don't=20
understand why would anyone make it NOW instead of LATTER, if he can=20
:-)

Joao

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

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

On Sun, 15 Sep 2002, Maurice LeBrun wrote:

> OK, I have built, installed, and tested 1.3.11 through 1.3.15,
> and found:
>
>     #define SWIG_init    initplplotc
>     #define SWIG_name    "plplotc"
>
> are used by 1.3.11 - 1.3.13, and
>
>     #define SWIG_init    init_plplotc
>     #define SWIG_name    "_plplotc"
>
> are used in 1.3.14 & 1.3.15.  Since it's in both of the last two versions it
> would seem to be a convention change and not a bug.  Jeez, I'd think this
> would warrant a major version number change since it's clearly not backward
> compatible.

We need the features of swig-1.3.x so we must use it, but it is an unstable
release series (like kernel 2.5.x) so you do expect changed features from
one 1.3.x release to the next. Also, the pace of change should slow as they
converge to the 2.0 version. Earlier this year they hoped to bring that out
this month.  I don't know how much, if at all, that schedule has slipped.

After some searching I just found that the convention change on the leading
underscore is explained in http://www.swig.org/Doc1.3/Python.html#n6.
Actually, I like that convention because it fits right with our needs to
distinguish the extension module name from the python wrapper module name.
In fact, Gary and I adopted the 'c' in plplotc for exactly that same reason,
but if we had been smarter back then, the underscore prefix would have been
a better (IMHO), and I would certainly be happy to adopt it now.

I don't know the significance of changing SWIG_init.  Gary, can you explain
that and/or make swig-1.3.15 work for us?  If so, I would be willing to
adopt that version in anticipation that it will be an easy step from there
to swig-2.0, once that comes out.

Alan

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

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > (2) If you also obtain success with those interface files, then please
 >  > compare them with what is generated by the latest-generation swig you
 >  > installed on your RH7.3 system, and please let me know what differences
 >  > there are.
 > 
 > Lots.  But the ones that look to be the likely culprits are:
 > 
 > < #define SWIG_init    initplplotc
 > < #define SWIG_name    "plplotc"
 > 
 > > #define SWIG_init    init_plplotc
 > > #define SWIG_name    "_plplotc"
 > 
 > The latter ones are those generated by swig 1.3.14.  Ugh.

OK, I have built, installed, and tested 1.3.11 through 1.3.15,
and found:

    #define SWIG_init    initplplotc
    #define SWIG_name    "plplotc"

are used by 1.3.11 - 1.3.13, and

    #define SWIG_init    init_plplotc
    #define SWIG_name    "_plplotc"

are used in 1.3.14 & 1.3.15.  Since it's in both of the last two versions it
would seem to be a convention change and not a bug.  Jeez, I'd think this
would warrant a major version number change since it's clearly not backward
compatible.

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

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

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

On Sun, 15 Sep 2002, Maurice LeBrun wrote:
>  [...] For the first time
> ever, I am seeing the plplot python bindings in action. :)

Great!

> < #define SWIG_init    initplplotc
> < #define SWIG_name    "plplotc"
>
> > #define SWIG_init    init_plplotc
> > #define SWIG_name    "_plplotc"
>
> The latter ones are those generated by swig 1.3.14.  Ugh.

Gary and Olof (separately) what version of swig are you using?

Alan

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

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

Maurice LeBrun writes:
 > Maurice LeBrun writes:
 >  > Alan W. Irwin writes:
 >  >  > Maurice, I just built the plplot (1.5) python interface on RH 7.3 without
 >  >  > any problems For example, I can run pythondemos.py in plplot/tmp without any
 >  >  > problems.
 >  >  > 
 >  >  > One potentially significant difference from your effort is I
 >  >  > used the attached python interface files that I generated with swig
 >  >  > on my Debian system.  Could you please do the following?
 >  >  > 
 >  >  > (1) See if the attached files work for you.  They of course should be placed
 >  >  > in bindings/python with the exact names I have given them.  The Makefile and
 >  >  > the symlinks set up in tmp by configure should take care of the rest.
 >  > 
 >  > Hi, I finally got around to doing this, and yes it works!  For the first time
 >  > ever, I am seeing the plplot python bindings in action. :)
 >  > 
 >  > So the difference is due to the change in version of swig.  I am using
 >  > 1.3.14 currently, so will back off to an older version as you suggested.
 > 
 > Stranger and stranger.  Having built and installed 1.3.11 on my system, I do
 > not get the result you did.  So far I've tried: 1.3.11, 1.3.14, 1.3.15, and
 > they all give the same result.

AAAHHH.. bogus.  Sorry, ignore, path problems.  My built version of 1.3.11
*does* give the same result as you got.  Now testing the others.

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

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

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

Maurice LeBrun writes:
 > Alan W. Irwin writes:
 >  > Maurice, I just built the plplot (1.5) python interface on RH 7.3 without
 >  > any problems For example, I can run pythondemos.py in plplot/tmp without any
 >  > problems.
 >  > 
 >  > One potentially significant difference from your effort is I
 >  > used the attached python interface files that I generated with swig
 >  > on my Debian system.  Could you please do the following?
 >  > 
 >  > (1) See if the attached files work for you.  They of course should be placed
 >  > in bindings/python with the exact names I have given them.  The Makefile and
 >  > the symlinks set up in tmp by configure should take care of the rest.
 > 
 > Hi, I finally got around to doing this, and yes it works!  For the first time
 > ever, I am seeing the plplot python bindings in action. :)
 > 
 > So the difference is due to the change in version of swig.  I am using
 > 1.3.14 currently, so will back off to an older version as you suggested.

Stranger and stranger.  Having built and installed 1.3.11 on my system, I do
not get the result you did.  So far I've tried: 1.3.11, 1.3.14, 1.3.15, and
they all give the same result.

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

RE: [Plplot-devel] decoupling drivers from libplplot

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

Alan W. Irwin writes:
 > On Tue, 3 Sep 2002, Maurice LeBrun wrote:
 > 
 > > Geoffrey Furnish writes:
 > >  > The last time I used the python binding in PLplot, I built a complete
 > >  > python from scratch, and installed the numeric module by hand, and did
 > >  > everything static.  So, I know how to do it if I go that way.  But I
 > >  > am under the impression that other PLplot developers aren't going that
 > >  > route.  What is the state of things in the Python universe these days?
 > >  > For example, is there an rpm for RedHat 7.3 that I could install which
 > >  > adds the numeric stuff to a stock Python install?
 > >
 > > I didn't find one for python2.2 when I went looking.
 > 
 > For python2.2 try http://prdownloads.sf.net/numpy/Numeric-22.0-1.i386.rpm.

Since I generally prefer rpm installs over tarball, I took a look and found:

$ rpm -qlp Numeric-22.0-1.i386.rpm
/home/dubois/linux/include/python2.2/Numeric/arrayobject.h
/home/dubois/linux/include/python2.2/Numeric/f2c.h
/home/dubois/linux/include/python2.2/Numeric/ranlib.h
/home/dubois/linux/include/python2.2/Numeric/ufuncobject.h
/home/dubois/linux/lib/python2.2/site-packages/Numeric.pth
/home/dubois/linux/lib/python2.2/site-packages/Numeric/ArrayPrinter.py
/home/dubois/linux/lib/python2.2/site-packages/Numeric/ArrayPrinter.pyc
/home/dubois/linux/lib/python2.2/site-packages/Numeric/FFT/FFT.py
/home/dubois/linux/lib/python2.2/site-packages/Numeric/FFT/FFT.pyc
/home/dubois/linux/lib/python2.2/site-packages/Numeric/FFT/__init__.py
/home/dubois/linux/lib/python2.2/site-packages/Numeric/FFT/__init__.pyc
/home/dubois/linux/lib/python2.2/site-packages/Numeric/FFT/fftpack.so
/home/dubois/linux/lib/python2.2/site-packages/Numeric/LinearAlgebra.py
/home/dubois/linux/lib/python2.2/site-packages/Numeric/LinearAlgebra.pyc
/home/dubois/linux/lib/python2.2/site-packages/Numeric/MA/MA.py
/home/dubois/linux/lib/python2.2/site-packages/Numeric/MA/MA.pyc
...

Whoops.  Hee hee.  I guess I'll stick with the tarball.  :)

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

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

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

Alan W. Irwin writes:
 > Maurice, I just built the plplot (1.5) python interface on RH 7.3 without
 > any problems For example, I can run pythondemos.py in plplot/tmp without any
 > problems.
 > 
 > One potentially significant difference from your effort is I
 > used the attached python interface files that I generated with swig
 > on my Debian system.  Could you please do the following?
 > 
 > (1) See if the attached files work for you.  They of course should be placed
 > in bindings/python with the exact names I have given them.  The Makefile and
 > the symlinks set up in tmp by configure should take care of the rest.

Hi, I finally got around to doing this, and yes it works!  For the first time
ever, I am seeing the plplot python bindings in action. :)

So the difference is due to the change in version of swig.  I am using
1.3.14 currently, so will back off to an older version as you suggested.

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

Lots.  But the ones that look to be the likely culprits are:

< #define SWIG_init    initplplotc
< #define SWIG_name    "plplotc"

> #define SWIG_init    init_plplotc
> #define SWIG_name    "_plplotc"

The latter ones are those generated by swig 1.3.14.  Ugh.

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

[Plplot-devel] Documentation (docbook source in the CVS repository as well as the results at the website) is updated

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

Please check out the new version of
http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.3/advanced.html.

That advanced chapter has been completely reorganized with a substantial
improvement to the introduction in the section now entitled "View Surfaces,
(Sub-)Pages, Viewports and Windows).

I have also included some documentation from Andrew of his FreeType work in
the Section entitled "Adding FreeType Library Support to Bitmap Drivers".
Please read that section and go out and implement FreeType support for your
favorite bitmapped drivers.

Alan

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

Linux-powered astrophysics
__________________________

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

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

On Wed, Sep 04, 2002 at 01:42:01PM -0700, Alan W. Irwin wrote:
> David, can you make the debian subdirectory available to CVS HEAD so I can
> try the build or is there some reason why the debian subdirectory should
> remain isolated in its own CVS branch?

I was just following what Rafael did.

The reason for having a separate branch (I think) is because there
were patches applied to other parts of the tree.  So technically,
the DEBIAN branch is a fork of the 5.1.0 release, not HEAD.  It
is occasionally difficult to make Debian packaging scripts work
with both HEAD and a release, but it is usually worth the effort.

I'm still under the assumption that Rafael is going to return to
the Debian packages =), but I'll continue to work slowly on them
until that time.



dave...

RE: [Plplot-devel] OpenVMS port of plplot 5.1.0

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

Thanks for your contribution.  Sorry for the delayed response.  You
can send these to me and I'll take a look at it.

Jean-Fran=E7ois PI=C9RONNE writes:
 > Hi all,
 >=20
 > I have successfully port plplot 5.1.0 on OpenVMS.
 >=20
 > I have just add 3 files:
 > build.vms
 > sys/vms/plconfig.h
 > sys/vms/pldevs.h
 >=20
 >=20
 > How can I submit these files for a proper inclusion into the standar=
d package ?

Re: [Plplot-devel] Define size of graphic / setting background color

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

On Tuesday 10 September 2002 17:46, Jo=E3o Cardoso wrote:
| On Thursday 25 July 2002 13:10, ste...@ks... wrote:
| | Hello,
| |
| | I just started using plplot for my project and I really like it so
| | far. I'm writing some code in C which uses the plplot-lib.
| |
| | But two small(??)  problems occured:
| |
| | 1. I didn't find out how to set the size of the output-graphics.
| | It's always 640x480 pixel (pbm). I already tried --geometrie and
| | plspage, but both with no success.
| |
| | 2. Since I want a graphics black on white background I've tried to
| | set the backround-color using 'plscolbg(0xFF,0xFF,0xFF);', but the
| | result is still white on black background.
| |
| | Anyone here got an idea how to solve my two problems ??
|
|  ./x01c -dev pbm -o po.pbm -geo 200x400 -bg ffffff && xv po.pbm
|
| works for me...
|
| Joao

oops... only now I saw the other answers -- I have more then one undred=20
plplot messages to parse :(

I'm back!

Joao

|
| | Thanks in advance,
| |       Stefan
| |
| |
| |
| |
| | -------------------------------------------------------
| | This sf.net email is sponsored by: Jabber - The world's fastest
| | growing real-time communications platform! Don't just IM. Build it
| | in! http://www.jabber.com/osdn/xim
| | _______________________________________________
| | Plplot-devel mailing list
| | Plp...@li...
| | https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Second report on freetype status

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

A change that Andrew sent me this morning fixed the segfault problem, and I
am now seeing antialiased fonts with PLplot for the first time!

For those of you who would like to try this for themselves on Linux, here is
the cookbook:

(1) Make sure the freetype 2 libraries and headers are installed on your
system.

(2) configure using the new --with-freetype option

(3) make

(4) cd tmp ; make x01c

(5) ./x01c -dev png -drvopt text,smooth -o test.png

These 5 steps are almost the complete extent of my testing so far.

Also, there are some caveats.

(1) There is a 180 degree orientation problem with the vertical labels
generated by x01c with -drvopt.  I presume Andrew will soon be able to fix
that.

(2) familied mode introduces more segfaults in some situations.  valgrind
testing in progress.

(3) The default font directory and fonts (see plfreetype.c) are hard coded
to be the correct locations if the Debian msttcorefonts package has been
installed.  If your truetype fonts reside in a different directory or have
different names, then you will have to set the appropriate environment
variables (see plfreetype.c for documentation).  Furthermore, even for my
situation I haven't yet found a truetype symbols font (the default is
hard-coded to use Arial instead).  Anybody have advice?

Clearly, the font-finding problems should be dealt with in a slick way
before --with-freetype is considered non-experimental. One promising XFree86
package called fontconfig for finding fonts in a way that works nicely
with the freetype library has just been announced by Keith Packard.  Because
of his fame and influence amongst the XFree86 community, I suspect this
package will become the standard so we may want to give it a try eventually.
Meanwhile, the environment variable approach is good enough for experimenting
with freetype.

Despite the caveats, what you can do with plfreetype is already impressive,
and I urge experimentation with trying a variety of examples with png and
jpeg and making the straightforward changes to other drivers to allow them
to use this infrastructure as well.  Anti-aliased fonts just look cool!

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] Define size of graphic / setting background color

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

On Thursday 25 July 2002 13:10, ste...@ks... wrote:
| Hello,
|
| I just started using plplot for my project and I really like it so
| far. I'm writing some code in C which uses the plplot-lib.
|
| But two small(??)  problems occured:
|
| 1. I didn't find out how to set the size of the output-graphics. It's
| always 640x480 pixel (pbm). I already tried --geometrie and plspage,
| but both with no success.
|
| 2. Since I want a graphics black on white background I've tried to
| set the backround-color using 'plscolbg(0xFF,0xFF,0xFF);', but the
| result is still white on black background.
|
| Anyone here got an idea how to solve my two problems ??

 ./x01c -dev pbm -o po.pbm -geo 200x400 -bg ffffff && xv po.pbm

works for me...

Joao

|
|
| Thanks in advance,
|       Stefan
|
|
|
|
| -------------------------------------------------------
| This sf.net email is sponsored by: Jabber - The world's fastest
| growing real-time communications platform! Don't just IM. Build it
| in! http://www.jabber.com/osdn/xim
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] RH 7.3 rpm's build without problems, now

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

I have not had a chance to install these rpm's yet, but I did cd to the tmp
location where everything is built, and the extremely intensive

plplot-test --flat

works like a charm there to produce all the non-interactive c, c++, fortran,
tcl, python, and octave postscript examples without any obvious errors.

So, Maurice, will you please give a plplot build from CVS HEAD another try
on your RH 7.3 system?  I am especially interested in whether your python
troubles are over like they are on the RH7.3 system available to me.

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] PLplot freetype status report under Linux

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

First, my thanks to Andrew for creating the plfreetype.c code. That code has
been designed to use the freetype library to handle fonts for plplot for
drivers (currently only gd.c) that are set up properly with the appropriate
drvopt options.

I just finished the configuration changes so if you specify --with-freetype,
plfreetype.o will be built and put into libplplot[d] under Linux.

Although the build is now working, I haven't yet been able to actually
execute the plfreetype code successfully under Linux (i.e., -dev png
-drivopt text produces an immediate segfault). However, I have used valgrind
to diagnose a memory management problem in one line in plfreetype.c, and
Andrew is presumably working on getting it fixed as I write this.

It is possible this is the last bug before the Linux version of PLplot can
use TrueType fonts.  This is an exciting prospect so hurry up, 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: [Plplot-devel] active surface size

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

On Fri, 6 Sep 2002, A. van der Lee wrote:
> How can the active surface size, i.e. the plotting area, on the screen be
> enlarged? The default window that pops up, is very small. That is similar
> to all the examples. I tried to change it with plspage, but that has to be
> used before the initialisation. I do not even initialise; I cannot even see
> that it happens in the exmaples. So why is that?

I believe this is controlled (if I understand your question) outside of
plplot.  Plplot only manages the contents of the frame.  The size is
determined (in your case) by Tcl/Tk.  So, something like:

plframe .p
.p configure -width 500 -height 500

will probably do the trick (do '.p configure' to see all the options).

However, I may have misunderstood your request.

cheers,

Vince.

p.s. thanks for moving your questions to the mailing lists.

[Plplot-devel] active surface size

[A. v. d. L. <avd...@un...>]

Hi,

I am new to plplot; I am using the tcl/tk binding on a windows98 system. I
got it into work, but I have some questions for which I cannot find the
answer in the documention or in the mailing lists.

Where are command like plstdwin en pframe documented? In any case not in
the online documentation.

How can the active surface size, i.e. the plotting area, on the screen be
enlarged? The default window that pops up, is very small. That is similar
to all the examples. I tried to change it with plspage, but that has to be
used before the initialisation. I do not even initialise; I cannot even see
that it happens in the exmaples. So why is that?=20

Many thanks for any help

Arie van der Lee
*******************************************
A. van der Lee
Institut Europ=E9en des Membranes (UMR 5635)
Universit=E9 de Montpellier II - cc 047
Place E. Bataillon
34095 Montpellier Cedex 5
FRANCE

visiting address: 300 Av. Prof. E. Jeanbrau

t=E9l.: 00-33-(0)4.67.14.91.35
FAX.: 00-33-(0)4.67.14.91.19
*******************************************

[Plplot-devel] valgrind patch for extended profiling support

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

For those of you using valgrind to analyze plplot, there is a new extension
(call tree tracing) to better support profiling with cachegrind (the
profiling part of valgrind) and therefore optimization choices.  See
http://www.weidendorfers.de/kcachegrind/index.html.

This site also has a KDE GUI for cachegrind.

Note I have not tried these cachegrind extensions, but I thought I should
mention them here because of the previous list interest in valgrind.

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
__________________________