plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Re: Debian package (5.2.0.cvs.20030219-1)

[Rafael L. <lab...@ps...>]

* Christophe TROESTLER <deb...@ti...> [2003-02-24 20:19]:

> On Mon, 24 Feb 2003, Rafael Laboissiere <lab...@ps...> wrote:
> > Just install both plplot-xwin and plplot-tcl.
> 
> Easy indeed.  I did not try that because, if my memory serves well,
> the previous versions of the two packages were mutually exclusive.

Thanks to the new dyndriver implementation.

> > Another question to the developers: does the tk driver needs the xwin
> > driver?  If yes, I have to add a dependency field to the Debian package.
> 
> Yes; installing the xwin driver corrected the problem.

Thanks.  I will fix this.

> BTW, it would be nice to have a Release file in
> http://plplot.sourceforge.net/resources/debian/ so as to be able to
> use /etc/apt/preferences to select the repository access policy.

Very good idea.  Will be done soon.  I will upload today a new set of cvs
packages to the apt repository @ SF.  The most visible improvement is the
inclusion of freetype support for the GD driver.  Png and jpeg outputs look
great when option "-drvopt text" is given.

-- 
Rafael

Re: [Plplot-devel] Re: Debian package (5.2.0.cvs.20030219-1)

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

On Monday 24 February 2003 17:45, Rafael Laboissiere wrote:
| * Christophe TROESTLER <deb...@ti...> [2003-02-24 18:31]:
...
| Another question to the developers: does the tk driver needs the xwin
| driver?

Yes.

Joao

Re: [Plplot-devel] Re: Debian package (5.2.0.cvs.20030219-1)

[Christophe T. <deb...@ti...>]

On Mon, 24 Feb 2003, Rafael Laboissiere <lab...@ps...> wrote:
> 
> A question for the other developers: Does this happened with the
> plplot-5.2.0 tarball?

No.  See below.

> > But one may want to use (test with) the xwin driver _and_ the tk driver...
> Just install both plplot-xwin and plplot-tcl.

Easy indeed.  I did not try that because, if my memory serves well,
the previous versions of the two packages were mutually exclusive.

> Another question to the developers: does the tk driver needs the xwin
> driver?  If yes, I have to add a dependency field to the Debian package.

Yes; installing the xwin driver corrected the problem.

BTW, it would be nice to have a Release file in
http://plplot.sourceforge.net/resources/debian/ so as to be able to
use /etc/apt/preferences to select the repository access policy.

Regards,
ChriS

[Plplot-devel] Re: Debian package (5.2.0.cvs.20030219-1)

[Rafael L. <lab...@ps...>]

* Christophe TROESTLER <deb...@ti...> [2003-02-24 18:31]:

> I installed them on a testing box with a bit of unstable (¹).  All the
> examples in /usr/share/doc/libplplot5/examples/c/ compile well.
> However, when I try to execute them and I select the tk driver (other
> drivers work fine), the tk window does not open well (it stays
> uniformly gray) and the program then asks
> 
> 	Enter device number or keyword (stream 1):
> 
> even though this is not requested in the source.  I have to kill the
> program. Any idea about what is wrong?

A question for the other developers: Does this happened with the
plplot-5.2.0 tarball?  It may be a problem with the PLplot Debian packages
only, or a bad combination of packages in your system.

> Also, why is the xwin driver removed from plplot-tcl ?  As I
> understand it, plplot-tcl is a separate package to allow the use of
> plplot without depending on tcl/tk.

Yes, this is the reason.

> But one may want to use (test with) the xwin driver _and_ the tk driver...

Just install both plplot-xwin and plplot-tcl.

Another question to the developers: does the tk driver needs the xwin
driver?  If yes, I have to add a dependency field to the Debian package.

-- 
Rafael

[Plplot-devel] Debian package (5.2.0.cvs.20030219-1)

[Christophe T. <deb...@ti...>]

On Mon, 24 Feb 2003, Rafael Laboissiere <lab...@ps...> wrote:
> 
> If yu are using Debian, you might be interested in the packages (for Debian
> testing) in:
>     http://plplot.sf.net/resources/

I installed them on a testing box with a bit of unstable (¹).  All the
examples in /usr/share/doc/libplplot5/examples/c/ compile well.
However, when I try to execute them and I select the tk driver (other
drivers work fine), the tk window does not open well (it stays
uniformly gray) and the program then asks

	Enter device number or keyword (stream 1):

even though this is not requested in the source.  I have to kill the
program. Any idea about what is wrong?

Also, why is the xwin driver removed from plplot-tcl ?  As I
understand it, plplot-tcl is a separate package to allow the use of
plplot without depending on tcl/tk.  But one may want to use (test
with) the xwin driver _and_ the tk driver...

Regards,
ChriS


(¹) dpkg -l iwidgets3.1 itcl3.1 itk3.1 libc6 tcl8.3 tk8.3
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  iwidgets3.1    3.1.0-6        [Incr Widgets] OOP Extension for TCL - Run-T
ii  itcl3.1        3.1.0-6        [Incr Tcl] OOP Extension for TCL - Run-Time 
ii  itk3.1         3.1.0-6        [Incr Tk] OOP Extension for TCL - Run-Time F
ii  libc6          2.3.1-13       GNU C Library: Shared libraries and Timezone
ii  tcl8.3         8.3.3-8        The Tool Command Language (TCL) v8.3 - Run-T
ii  tk8.3          8.3.3-9        The Tk toolkit for TCL and X11 v8.3 - Run-Ti

Re: [Plplot-devel] Font problem

[Robert S. <ro...@sc...>]

On Mon, Feb 24, 2003 at 04:06:36PM +0100, Rafael Laboissiere wrote:
> If yu are using Debian, you might be interested in the packages (for Debian
> testing) in:
> 
>     http://plplot.sf.net/resources/

Good idea, but nevertheless I would like to be able to compile it from
scratch. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: [Plplot-devel] Font problem

[Robert S. <ro...@sc...>]

Alan, 

On Mon, Feb 24, 2003 at 08:11:56AM -0800, Alan W. Irwin wrote:
> I must guess here since you have given no details, but you probably
> tried to use make check which is currently only partially supported.

Hmm, the colleague who tried it just promised that he didn't run 'make
check', he just did 'make install' as root. After he changed --prefix=
to somewhere else it seems to work now!

> For the tarball version you should not run bootstrap.sh since it has already
> been done for you with the correct autotools versions.  Instead, just run
> configure; make; make install.

... which is what I did: 

  robert@ganymed:~/tmp/plplot-5.2.0> ./configure --enable-xwin --enable-ps --enable-xterm --enable-pnm

I forgot to mention that I try this with plplot-5.2.0. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: [Plplot-devel] Font problem

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

On Mon, 24 Feb 2003, Robert Schwebel wrote:

> Hi,
>
> on a SuSE 7.3 system we see this error while trying to run the x01c
> example:
>
> ----------8<----------
> *** PLPLOT ERROR ***
> Unable to open or allocate memory for font file
> Program aborted
> ---------->8----------
>
> Is this a known issue? Do I have to set some environment variables
> first?

I must guess here since you have given no details, but you probably tried to
use make check which is currently only partially supported.  In order for
that to work you must run make install first to install data such as fonts
and drivers in the configured install location.  Probably a cleaner
alternative to make check is to run make install, then cd to the *installed*
version of examples/c, then make x01c; ./x01c .

>
> Another thing is that on Debian unstable libtool fails:
>
> ----------8<----------
> make[2]: Entering directory `/home/robert/tmp/plplot-5.2.0/bindings/f77'
> /bin/sh ../../libtool --mode=compile    -c -o strutil.lo `test -f
> 'strutil.f' || echo './'`strutil.f
> libtool: unrecognized option `-c'
> Try `libtool --help' for more information.
> make[2]: *** [strutil.lo] Error 1
> make[2]: Leaving directory `/home/robert/tmp/plplot-5.2.0/bindings/f77'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/robert/tmp/plplot-5.2.0/bindings'
> make: *** [all-recursive] Error 1
> robert@ganymed:~/tmp/plplot-5.2.0> libtool --version
> ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
> ----------8<----------
>
> Which version is known to work? This should be put into the FAQ...

For the tarball version you should not run bootstrap.sh since it has already
been done for you with the correct autotools versions.  Instead, just run
configure; make; make install.

However, you do need to run bootstrap.sh if you want to use the cvs version
of Plplot (now stabilizing for our next release).  In that case, you must
use the following exact versions of autotools: autoconf-2.57,
automake-1.7.2, and libtool-1.4.3.  (We have to be careful with autotools
versions because those various tools are changing so rapidly with respect
to each other and overall.)

Your comment about the FAQ is a good one.  PLplot-5.2.0 has an enormous
number of changes under the hood compared to 5.1.0 (complete driver and
library reorganization, changing from autoconf to autotools configuration),
but unfortunately there was no time to document these changes, and the
documentation is still almost entirely for the 5.1.0 version. For our next
release in April, I hope to close this documentation gap a bit, but my time
continues to be quite limited so it would be nice to find additional
volunteers to help out.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Font problem

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

On Monday 24 February 2003 14:52, Robert Schwebel wrote:
| Hi,
|
| on a SuSE 7.3 system we see this error while trying to run the x01c
| example:
|
| ----------8<----------
| *** PLPLOT ERROR ***
| Unable to open or allocate memory for font file
| Program aborted
| ---------->8----------
|
| Is this a known issue? Do I have to set some environment variables
| first?


If you are using the last plplot release you have to "make install" 
before using it.

Joao

Re: [Plplot-devel] Font problem

[Rafael L. <lab...@ps...>]

* Robert Schwebel <ro...@sc...> [2003-02-24 15:52]:

> Another thing is that on Debian unstable libtool fails: 

If yu are using Debian, you might be interested in the packages (for Debian
testing) in:

    http://plplot.sf.net/resources/

-- 
Rafael

[Plplot-devel] Font problem

[Robert S. <ro...@sc...>]

Hi, 

on a SuSE 7.3 system we see this error while trying to run the x01c
example: 

----------8<----------
*** PLPLOT ERROR ***
Unable to open or allocate memory for font file
Program aborted
---------->8----------

Is this a known issue? Do I have to set some environment variables
first? 

Another thing is that on Debian unstable libtool fails: 

----------8<----------
make[2]: Entering directory `/home/robert/tmp/plplot-5.2.0/bindings/f77'
/bin/sh ../../libtool --mode=compile    -c -o strutil.lo `test -f
'strutil.f' || echo './'`strutil.f
libtool: unrecognized option `-c'
Try `libtool --help' for more information.
make[2]: *** [strutil.lo] Error 1
make[2]: Leaving directory `/home/robert/tmp/plplot-5.2.0/bindings/f77'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/robert/tmp/plplot-5.2.0/bindings'
make: *** [all-recursive] Error 1 
robert@ganymed:~/tmp/plplot-5.2.0> libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36)
----------8<----------

Which version is known to work? This should be put into the FAQ...

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: [Plplot-devel] PLplotOO + adding Doug Hunt's "mem" driver

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

On Sun, 23 Feb 2003, Joao Cardoso wrote:

> On Sunday 23 February 2003 16:52, Rafael Laboissiere wrote:
> > PLplotOO was writen for PLplot 5.1.0, but I succeeded to patch it for the
> > current CVS sources.

That sounds like wonderful progress, Rafael.

> > [...]
> > I will eventually package the PDL bindings for Debian, so that the PLplot
> > suite will be complete for at least one Operational System in the Universe.

;-)

> > I have already a version here ready for cvs commit, including the addition
> > of the documentation for plsmem in doc/docbook/api.xml.

> I see no problem, go ahead.
> Joao

I agree.  Go for it!

And thanks very much for including the documentation.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] PLplotOO + adding Doug Hunt's "mem" driver

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

On Sunday 23 February 2003 16:52, Rafael Laboissiere wrote:
> As you probably remember, Doug Hunt has develop the great PLplot bindin=
gs
> for PDL (Perl Data Language, see http://pdl.perl.org).  In his package,
> there is also a object oriented module called PLplotOO:
>
>   =20
> http://search.cpan.org/author/DHUNT/PDL-Graphics-PLplot-0.18/PLplotOO.p=
m
>
> It will be great to see this page:
>
>     http://pdl.perl.org/demos/plot2D_en.html
>
> with PGPLOT replaced by PLplot!
>
> PLplotOO was writen for PLplot 5.1.0, but I succeeded to patch it for t=
he
> current CVS sources.
>
> I will completely abandon the Perl5 bindings project that is currently =
in
> CVS.  Doug's approach is far superior than mine and has the big advanta=
ge
> of being PDL-native.  As a matter of fact, instead of the arcane SWIG
> interface that I developped for the Perl5 bindings, the PDL bindings us=
e a
> PDL-specific interface based on a *.pd file.  Much cleaner, much better=
=2E
>
> I will eventually package the PDL bindings for Debian, so that the PLpl=
ot
> suite will be complete for at least one Operational System in the Unive=
rse.
>
> Now, Doug told me that a forthcoming version of the PLplotOO module wil=
l
> need a feature that is present in his patched sources of PLplot: a new
> driver called "mem", which plots into a user-supplied memory space (X, =
Y,
> <R,G,B>).
>
> He send to me the source file mem.c and I integrated it into PLplot's
> source and configuration system.  The only caveat is that this new driv=
er
> needs the addition of a function to the API (in src/plcore.c), called
> plsmem:
>
>     /*
>       Set the memory area to be plotted (with the 'mem'driver) as the '=
dev'
>       member of the stream structure.  Also set the number
>       of pixels in the memory passed in in 'plotmem'.
>       Plotmem is a block of memory maxy by maxx by 3 bytes long, say:
>       480 x 640 x 3 (Y, X, RGB)
>
>       This memory will be freed by the user!
>     */
>
>     void
>     c_plsmem(PLINT maxx, PLINT maxy, void *plotmem)
>     {
>        plsc->dev =3D plotmem;
>        plP_setphy (0, maxx, 0, maxy);
>     }
>
> I have already a version here ready for cvs commit, including the addit=
ion
> of the documentation for plsmem in doc/docbook/api.xml.  However, since
> this adds things to the API (notice that this does _not_ make the libra=
ry
> backwards incompatible), I decided to ask your opinion before I do the
> actual commit.  I do not see problems with the changes, besides the fac=
t
> that a new API function is totally specific to the mem driver.
>
> If you do not care, or if you are silent (I promise to wait for a coupl=
e of
> hours, at least :-) I will cvs commit the changes.

(Half an hour later...)

I see no problem, go ahead.
Joao

[Plplot-devel] PLplotOO + adding Doug Hunt's "mem" driver

[Rafael L. <lab...@ps...>]

As you probably remember, Doug Hunt has develop the great PLplot bindings
for PDL (Perl Data Language, see http://pdl.perl.org).  In his package,
there is also a object oriented module called PLplotOO:

    http://search.cpan.org/author/DHUNT/PDL-Graphics-PLplot-0.18/PLplotOO.pm

It will be great to see this page:

    http://pdl.perl.org/demos/plot2D_en.html

with PGPLOT replaced by PLplot!  

PLplotOO was writen for PLplot 5.1.0, but I succeeded to patch it for the
current CVS sources.

I will completely abandon the Perl5 bindings project that is currently in
CVS.  Doug's approach is far superior than mine and has the big advantage of
being PDL-native.  As a matter of fact, instead of the arcane SWIG interface
that I developped for the Perl5 bindings, the PDL bindings use a
PDL-specific interface based on a *.pd file.  Much cleaner, much better.

I will eventually package the PDL bindings for Debian, so that the PLplot
suite will be complete for at least one Operational System in the Universe.

Now, Doug told me that a forthcoming version of the PLplotOO module will
need a feature that is present in his patched sources of PLplot: a new
driver called "mem", which plots into a user-supplied memory space (X, Y,
<R,G,B>).

He send to me the source file mem.c and I integrated it into PLplot's source
and configuration system.  The only caveat is that this new driver needs the
addition of a function to the API (in src/plcore.c), called plsmem:

    /*
      Set the memory area to be plotted (with the 'mem'driver) as the 'dev'
      member of the stream structure.  Also set the number
      of pixels in the memory passed in in 'plotmem'.
      Plotmem is a block of memory maxy by maxx by 3 bytes long, say:
      480 x 640 x 3 (Y, X, RGB)
    
      This memory will be freed by the user!
    */
    
    void
    c_plsmem(PLINT maxx, PLINT maxy, void *plotmem)
    {
       plsc->dev = plotmem;
       plP_setphy (0, maxx, 0, maxy);
    }
    
I have already a version here ready for cvs commit, including the addition
of the documentation for plsmem in doc/docbook/api.xml.  However, since this
adds things to the API (notice that this does _not_ make the library
backwards incompatible), I decided to ask your opinion before I do the
actual commit.  I do not see problems with the changes, besides the fact
that a new API function is totally specific to the mem driver.

If you do not care, or if you are silent (I promise to wait for a couple of
hours, at least :-) I will cvs commit the changes.

-- 
Rafael

[Plplot-devel] PLplot PDF manual

[Rafael L. <lab...@ps...>]

There has been some improvements in the PDF form of the Dobook documentation
for PLplot.  The Resources/DocBook page at plplot.sf.net has not yet been
updated, but I put a preview of the PDF file in 

    http://people.debian.org/~rafael/plplot-5.2.0.cvs.20030217.pdf

Go read, browse, download, print, and bind!  It looks quite pretty now (it
is just a little bit to late to offfer it to your girlfriend for Valentine
:-).

-- 
Rafael

Re: [Plplot-devel] How to PLplot (CVS sources, at least)

[Rafael L. <lab...@ps...>]

* Alan W. Irwin <ir...@be...> [2003-02-21 14:59]:

> This is another API change.  Use plend for your absolutely last call to
> plplot which closes everything to do with the library including deallocating
> all memory resources, etc.  Otherwise use plend1.  See discussion
> (especially near end of thread) at
> http://sourceforge.net/mailarchive/forum.php?thread_id=1405374&forum_id=2199.

Thanks.

-- 
Rafael

Re: [Plplot-devel] How to PLplot (CVS sources, at least)

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

On Fri, 21 Feb 2003, Rafael Laboissiere wrote:

> This simple program:
> [...] crashes PLplot.

This is another API change.  Use plend for your absolutely last call to
plplot which closes everything to do with the library including deallocating
all memory resources, etc.  Otherwise use plend1.  See discussion
(especially near end of thread) at
http://sourceforge.net/mailarchive/forum.php?thread_id=1405374&forum_id=2199.

Alan

__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________

[Plplot-devel] How to PLplot (CVS sources, at least)

[Rafael L. <lab...@ps...>]

This simple program:

    $ cat crash.c
    #include "plplot.h"
    
    int
    main (int argc, char** argv)
    {
        plParseOpts(&argc, argv, PL_PARSE_FULL);
        plsdev ("xfig");
        plsfnam ("foo.fig");
        plinit ();
        plend ();
        plsdev ("png");
        plsfnam ("bar.png");    
        plinit ();
        plend ();
    }

crashes PLplot.  It says:

    $ ./crash -debug
    plLoadDriver: Device not loaded!
    plLoadDriver: tag=xfig, drvidx=11
    plLoadDriver: Trying to load xfig on
    /usr/lib/plplot5.2.0.cvs.20030219/data/../driversd/xfig
    Opened foo.fig
    Segmentation fault
    
It seems that this bug is related to a memory management problem in plend,
but I am not sure whether it has existed before I started changing the code.
If you have an old tree around, could you please test the program above?
    
-- 
Rafael

[Plplot-devel] Changes in API and SOVERSION

[Rafael L. <lab...@ps...>]

Hi again,

I am trying to compile the PDL bindings for PLplot
(http://search.cpan.org/author/DHUNT/PDL-Graphics-PLplot-0.18/PLplotOO.pm)
and came accross a compilation error due to a change in the API.  Here is
the relevant CVS log entry:

    RCS file: /cvsroot/plplot/plplot/src/plline.c,v
    Working file: plline.c
    head: 1.26
    revision 1.23
    date: 2002/06/21 23:24:41;  author: airwin;  state: Exp;  lines: +12 -12
    Changed API of plpoly3 so that negative dimension n has no special
    significance (except you will have less than the minimum 3 points), and
    there is an additional argument ifcc. [...]

This introduced a backwards incompatible change in the API.  That's fine,
since software must evolve or die.  However, this is completely incoherent
with the fact that we kept the major number for the library soversion (5.1.0
-> 5.2.0).  The present release of PLplot should have had a library
soversion = 6.0.0. 

It would be better to create a new function (plpolyl3, say) and make plpoly3
a wrapper to it. We could implement this idea to clear up the soversion mess
for the forthcomming 5.2.1 release.  We can also bump the library soversion
to 6.0.0. Another possibility is to keep things as they are and send a note
of excuse to our users.

At any rate, we must pay attention to this problem in the future.

-- 
Rafael

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

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

On Thu, 20 Feb 2003, [iso-8859-1] Jo=E3o Cardoso wrote:

> At last, Alan has been my only interlocutor in this issue, and he does
> not seems sensible to this "make install" problem.

Joao, you should know from my previous posts on this matter that this
assertion is false.

On the contrary, I understand how the make install latency could be
annoying, and I will support any "make check" solution that does not have
any confusion/ambiguity between the build and install locations. For older
versions of plplot with this ambiguity we wasted many man-hours trying to
confirm tmp-area bugs which turned out to be caused by (or hidden by) prior
buggy installs. All I want to do is avoid this bad situation in the future.

The configuration process already has all the required information on the
various build locations of everything required for PLplot to run so in
principle it is entirely possible to support "make check" without any
build/install location ambiguity, but it will take a fair amount of thought
about the design. There is absolutely nothing stopping you from designing
and implementing such a solution if you are willing to be careful of this
one build/install ambiguity issue.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting softwar=
e
package (plplot.org).

__________________________

Linux-powered Science
__________________________

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

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

On Thursday 20 February 2003 16:00, Rafael Laboissiere wrote:
| [ Moving to plplot-devel. ]
|
| * Jo=E3o Cardoso <jc...@fe...> [2003-02-20 15:40]:
| > In my sources, I use a PLplot global variable called build_tree
| > that says if the program being run was invoked inside the build
| > tree(*); if it was , then the path of the searched file in the
| > build tree is used, else the usual search path is used. This works
| > fine for most drivers, fonts and map files.
| > The tk driver is an exception, as it needs to find plserver, and
| > tcl/tk also needs its auto_path to be setup; in my sources this is
| > also working fine.
| > However,  I don't like the (tk) solution, as it is not general.
| > There is also the problem of having a global variable, build_tree,
| > which is ugly.
|
| If your solution works and does not interfere with the normal mode of
| operation why don't you commit the changes?

As I say above, the tk special case makes me believe that other similar=20
situations (tkwin?) can appear, creating yet another special case. I=20
don't like more than one special case :)

I also don't like to have a global variable, even if only one -- aside=20
from plsc in plcore.c, of course.

At last, Alan has been my only interlocutor in this issue, and he does=20
not seems sensible to this "make install" problem.

Joao

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

[Rafael L. <lab...@ps...>]

[ Moving to plplot-devel. ]

* João Cardoso <jc...@fe...> [2003-02-20 15:40]:

> In my sources, I use a PLplot global variable called build_tree that 
> says if the program being run was invoked inside the build tree(*); if 
> it was , then the path of the searched file in the build tree is used, 
> else the usual search path is used. This works fine for most drivers, 
> fonts and map files.
> The tk driver is an exception, as it needs to find plserver, and tcl/tk 
> also needs its auto_path to be setup; in my sources this is also 
> working fine. 
> However,  I don't like the (tk) solution, as it is not general.
> There is also the problem of having a global variable, build_tree, which 
> is ugly.

If your solution works and does not interfere with the normal mode of
operation why don't you commit the changes?  

-- 
Rafael

[Plplot-devel] Needs Info About Dynamic Drivers

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

Hi All,

How do I load the dynamic drivers? I am facing some problems in loading dynamic
drives as given below. I have built tl/tk driver on Solaris8, ActiveTcl8.4.
% package require Itcl
3.2
% package require Itk
3.2
% package require Pltk
looking for driver file: /usr/ActiveTcl/lib/plplot5.2.0/drivers/tkd_drv.so
looking for driver file: /usr/ActiveTcl/lib/plplot5.2.0/drivers/tk_drv.so
5.2.0
% plfram .f
Unable to load driver: xwin_drv.

*** PLPLOT ERROR ***
Unable to load driver
Program aborted

Does anybody has a clue what is going wrong here?

Thanks for any help.

Re: [Plplot-devel] Use $(VAR) instead of @VAR@ in Makefile.am

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

Rafael Laboissiere writes:
 > In doing my last changes, I noticed that in many Makefiles.am, constructs
 > like @MATWRAP@ and @MKOCTFILE@ are used.  This is bad practice.  Use
 > $(MATWRAP) and $(MKOCTFILE) instead, which is the standard, advised style.
 > 
 > The reason for this is simple: variables could be replaced in the invocation
 > of make, like this: 
 > 
 >     make MKOCTFILE=my-mkoctfile
 > 
 > Using the construct @VARIABLE@ prevents doing that.
 > 
 > This is not a particular problem in the PLplot project, since I guess that
 > people barely need the variable substitution feature.  However, try to
 > follow the good usage rule, please. 

I *thought* I noticed some odd behaviors when testing plplot using this style
of build, weeks ago.  Glad you got to the bottom of it.

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

Re: [Plplot-devel] Use $(VAR) instead of @VAR@ in Makefile.am

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

On Wed, 19 Feb 2003, Rafael Laboissiere wrote:

> In doing my last changes, I noticed that in many Makefiles.am, constructs
> like @MATWRAP@ and @MKOCTFILE@ are used.  This is bad practice.  Use
> $(MATWRAP) and $(MKOCTFILE) instead, which is the standard, advised style.

I agree.  A lot of those crept through from the old way of doing things, and
I appreciate your willingness to clean it up, and I will try not to make
more problems like this.

Another part of the form I believe we should be careful of is continuations
(especially in lists).  I noticed one or two problems with that recently. I
don't know whether these were leftovers from the old days or something that
had been recently introduced in error. The old Makefile standard was always
to continue with a "space \" at the end of the line followed by a tab at the
start of the continued line.  It doesn't matter to GNU make, but I believe
it may be important to maintain this old continuation style for
cross-platform use. For 5.1.0 we demanded everybody use GNU make, but with
the autotools approach our users are supposed to be able to use native make
again, and some versions may have this constraint on their continuation
style.  This of course would not matter if automake parsed and massaged the
continuations, but I don't think it does.  Last time I looked it just passed
them through with the continuation style imposed in the Makefile.am file.

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the Canadian Centre for Climate Modelling and
Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software
package (plplot.org).

__________________________

Linux-powered Science
__________________________