plplot-devel — Technical discussion about PLplot development

[Plplot-devel] necessary modifications for building a DLL

[Joachim W. <wu...@cr...>]

For context, see previous mail (DLL generated ..).

The main modification of the distributed Win binding
consists in eliminating the following lines from plstub.cpp:

extern void *h_pldll;

extern "C" int APIENTRY
  DllMain(HINSTANCE hInstance,DWORD dwReason,LPVOID lpReserved) {
 =20
  if (dwReason =3D=3D (unsigned long) DLL_PROCESS_ATTACH) {
          AfxMessageBox("dll init",MB_OK);
 	  h_pldll =3D hInstance;
  } else if (dwReason =3D=3D (unsigned long) DLL_PROCESS_DETACH) {
          AfxMessageBox("dll done",MB_OK);
  }
  return 1;
}

No replacement is needed; everything seems to be handled by
the many settings hidden in various parts of the VS environment.

 - Joachim

[Plplot-devel] problems with plSetOpt: driver-dependent options; no-pause mode under MSWindows

[Joachim W. <wu...@cr...>]

Since plSetOpt is not yet documented in the
on-line reference, here a clue:
For generic options, use
    plSetOpt("<option_name>", "<argument>"),
e.g.
    plSetOpt("np", "").
For driver-specific options, in contrast, use
    plSetOpt("drvopt", "<option_name>=3D<argument>"),
e.g.
    plSetOpt("drvopt", "color=3D0").

The W2000 driver has the option "hwnd" which takes
as argument a pointer to a HWND handle. To use
this, one has to convert the pointer through=20
something like sprintf(drvopt_arg, "hwnd=3D%x", m_hwnd)
to a string; I doubt whether this has ever been
tested. A more sensible way to influence the
plot window from the main application would be
to pass a number of individual parameters like
xpos, xwidth, title, ... Is there any convention
I should follow in introducing such parameters ?

The option "np" has hitherto been ineffective in
the Win binding. To correct this, it might be
sufficient to chnge one line in win3.cpp into
   dev->nextPlot =3D pls->nopause;

- Joachim

[Plplot-devel] breakthrough in porting plplot to MS Windows: DLL generated

[Joachim W. <wu...@cr...>]

I succeeded in generating a shared library
under Win2000 with Visual Studio C++ 6.0
(as opposed to the static library generated
by the makefiles of the current plplot
distribution 5.1.0). This is certainly a
breakthrough in making plplot acceptable
for industrial applications.

There was not one single clue to the problem:
I just had to overcome a number of misunderstandings,
and to change a very few lines in the code. I have
still think about how to document my experiences.

To start, I will answer some of the questions I posed
in the course of the last ten days, and pose some new
questions to the maintainers of plplot. To facilitate
later search in the archive, I will break my feedback
into a couple of short mailings. Stay tuned.

- Joachim

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

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

On Tuesday 10 December 2002 08:07, Alan W. Irwin wrote:
> Apparently Joao has sequences of plinit, plend, plinit in his "x" octav=
e
> examples which violated an assumption I had made that a call to plend w=
as
> the last possible use of libplplot in a programme.  With that assumptio=
n I
> could release libltdl memory resources in plend.  I have now fixed this=
 so
> the libtldl memory resources are never released.  Now on my system all =
of
> Joao's "x" examples run and all his "p" examples also run except for p7=
 and
> p15. Apparently Joao knows what the p7 trouble is so that leaves only p=
15
> as the last octave example where there is unexplained trouble.
>
> This is a nice step forward, but nevertheless, I am now having second
> thoughts about this "fix" because I like the idea of plend being the la=
st
> possible call to the libplplot library so we could release all dynamic
> driver (and in my case the libltdl) memory resources there.  Those are =
the
> memory resources that are allocated when the library is initialized so =
this
> is the only possible place to release the resources again.  But that ca=
nnot
> be done if our users are free to call plinit again after plend is calle=
d.
>
> I would like to hear the developer's thoughts (especially Joao's though=
ts)
> on this topic. For example, there should be a way for the octave x exam=
ples
> to work using pladv without having to call any libplplot function after
> plend is called at the very end of the x plots.  I assert that because =
all
> the normal x examples in C are done that way so I assume octave can fol=
low
> that model.

That is not the problem. The problem is an user program finish doing a pl=
ot,=20
and thus closing the plot using plend(). Latter on, in the same program,=20
another plot is needed, thus plinit() is again called.
The x??c examples all finish with plend(), thus the octave counterparts a=
lso=20
do the same. But *one* instance of Octave wants to run *all* x??c demos, =
thus=20
the several plinit/plend.

I often do that in Octave, closing a plot figure, opening another, ... an=
d all=20
users of interactive languages certainly do the same. Of course, I could =
use=20
plinit/plend1(), but then, when would I call plend()? I really never know=
=20
when the user has finished opening/closing plot windows or finished using=
=20
Octave (*).

I never bother releasing memory that will be relased anyway by the OS whe=
n a=20
program finish. At least in unix, when a program finish, the memory owned=
 by=20
the program will be released.

Joao

(*)- I could register with atexit() a function that would do the cleanup,=
 but=20
what for? The OS does it for me.

> Alternatively, there is the python or tcl model where plinit is
> called once before all examples are plotted, every example restores ini=
tial
> values (colour maps) when its part of the plotting is done, and plend i=
s
> called once at the end (see xw??.py and pythondemos.tcl to see how this
> approach all fits together).  Could that "python" approach work for oct=
ave,
> 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
> __________________________
>
>
>
> -------------------------------------------------------
> 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] plinit, plend, plinit sequence now works, but I am having second thoughts

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

Maurice LeBrun writes:
 > This also includes proposals for change to how we do it now -- i.e. the
 > behavior of plinit().  I've always been somewhat bothered by the way stream 0
 > vs stream N is handled (this bugged me back in '94 but I wasn't exactly
 > swimming in free time then either).

BTW just offhand the only things needed to implement this fully-consistent
model for library & initialization are: 
 - modify plinit() to call plmkstrm() and plcpstrm() (example in plframe.c) 
 - plend() doesn't touch either global data or stream 0 "class data" (leave
 that for the OS)

Should be pretty easy.

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

Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

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

I can't tell you the specific answer to your questions due to how maniacally
busy I am these days (having just joined Lightspeed Semiconductor), but I can
elucidate some of the plplot design ideas that have historically been
un-documented.  And, I can give it in an object-oriented context, which
(because it is "canonical") is a lot nicer than the "this is the way it should
work" approach I've used historically. :)

This also includes proposals for change to how we do it now -- i.e. the
behavior of plinit().  I've always been somewhat bothered by the way stream 0
vs stream N is handled (this bugged me back in '94 but I wasn't exactly
swimming in free time then either).

When plplot starts, you have the statically pre-allocated stream, stream 0.
Yes the stream 0 that I hate b/c it's not allocated on the heap like a proper
data-structure/object (in the plframe widget I automatically start from stream
1).  

So stream 0 is like a class definition and an instance rolled into one.  What
I think we need to do is get rid of the "instance" part of this and leave
stream 0 as a "class definition" only.  In this case all the command line
arguments and initial pls...() calls (before plinit) serve to override the
default initializion of the class variables, i.e. set stream 0 parameters only

In other words, stream 0 becomes the template for all plplot streams.  You can
use it, but once you've called plinit() you have your own "instance" of the
plplot "object" -- i.e. you have a new stream with all the relevant state info
copied from stream 0.  If you change it, it dies when your stream dies with
plend1().

If you really want to change stream 0 (i.e. the "plplot object" "class data")
you can always set your stream number to 0 and fire away.

To summarize:

plinit() creates a new stream, copied from stream 0
plend1() deletes that stream
plend() deletes all streams, except of course stream 0 which is "class data"

Let me know if any of this helps.

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

[Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

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

Apparently Joao has sequences of plinit, plend, plinit in his "x" octave
examples which violated an assumption I had made that a call to plend was
the last possible use of libplplot in a programme.  With that assumption I
could release libltdl memory resources in plend.  I have now fixed this so
the libtldl memory resources are never released.  Now on my system all of
Joao's "x" examples run and all his "p" examples also run except for p7 and
p15. Apparently Joao knows what the p7 trouble is so that leaves only p15 as
the last octave example where there is unexplained trouble.

This is a nice step forward, but nevertheless, I am now having second
thoughts about this "fix" because I like the idea of plend being the last
possible call to the libplplot library so we could release all dynamic
driver (and in my case the libltdl) memory resources there.  Those are the
memory resources that are allocated when the library is initialized so this
is the only possible place to release the resources again.  But that cannot
be done if our users are free to call plinit again after plend is called.

I would like to hear the developer's thoughts (especially Joao's thoughts)
on this topic. For example, there should be a way for the octave x examples
to work using pladv without having to call any libplplot function after
plend is called at the very end of the x plots.  I assert that because all
the normal x examples in C are done that way so I assume octave can follow
that model. Alternatively, there is the python or tcl model where plinit is
called once before all examples are plotted, every example restores initial
values (colour maps) when its part of the plotting is done, and plend is
called once at the end (see xw??.py and pythondemos.tcl to see how this
approach all fits together).  Could that "python" approach work for octave,
Joao?

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] Change from lt_dlopen to lt_dlopenext in src/plcore.c

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

I forgot to make this change earlier when I was just getting libltdl to work
on Linux.  From info libtool, all this change does is look for a variety of
suffixes if it cannot find the exact file name you specify.  I just tested
that lt_dlopenext works exactly like lt_dlopen on Linux where the shared
object suffix is .so.  Apparently, the shared object suffix is also .so for
OSF1, so I believe this change won't affect the OSF1 testing that Joao is
doing. What we need is additional tests of lt_dlopenex on platforms with
different suffixes for shared objects.

Does anybody have access to a HPUX machine where apparently the suffixes are
.sl rather than .so?  That (assuming you configure --enable-dyndrivers)
would be a definitive test of lt_dlopenext (and of course lots of other
stuff where HPUX apparently does things in their own unique way).

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] "make check" support installed for c++, f77, and tk examples

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

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

> To make things clear: I just want to avoid the need to do a "make
> install".

> [...]The problem is not how to generate libraries, but how/where will the
> mother app (tcl or python) find them.
> Anyhow, if you say that you will be able to run the tcl and python
> examples *without* a "make install", then I will be happy. But in the
> original post you said:
>
>     "The python examples assume an installed location for the
>      wrapper library, and the tcl and tk examples are even more
>      dependent on installed data."
>
> Again, I think that there is no problem for now if only data needs to be
> installed. With "data" I *don't* mean the drivers. And yes, now I see,
> the drivers are a good example to discuss this issue, because the
> drivers are a kind of "extension modules" of plplot.
>
> How do you intend to load the drivers without a "make install"? In the
> installed directory, you can find a driver,
>     /usr/local/test/lib/plplot5.1.0/drivers/xwin_drv.so
>
> but in the build directory you only found
>    drivers/xwin_drv.la
>    drivers/xwin_drv_la-xwin.lo
>    drivers/xwin_drv_la-xwin.o -> xwin_drv_la-xwin.lo
>
> the real driver is in
>    drivers/.libs/xwin_drv.la@
>    drivers/.libs/xwin_drv.so*
>    drivers/.libs/xwin_drv.lai
>    drivers/.libs/xwin_drv.soT*
>
> When the plplot library wants to load a driver, what will it look for?
> xwin_drv.so, right? Or is that changed? That object can only be found at
> the installed directoy or hidden in drivers/.libs.
> [...]

We have complete control of where to find the drivers.  Look in plcore.c
at

        sprintf( drvspec, "%s/%s/%s",
=09 DATA_DIR, "../drivers", driver->drvnam );

Another stanza would have to be put in there to look in an alternative
location.  Also look elsewhere in src/*.c for DATA_DIR to find out
all locations that are affected.

I am not so familiar with the tcl part, but I believe in that case the
plplot initialization scripts define where the dynloaded shared objects are
so it is those scripts that would have to be modified if you want this no
"make install" capability.  Similar remarks pertain to the location
of the plplot tcl initialization scripts as well.

For python, the location of the plplotc module is in
examples/python/plplot_python_start.py(.in).  So we have complete control o=
f
specifying the module location in that case as well.

So to sum this up, with some work this should all be doable, but there are =
a
a fair number of places in the code and scripts that are affected so I woul=
d
still like to put this (the "no make install" option for lack of a better
description) under firm control of a configuration option.

Alan

Re: [Plplot-devel] "make check" support installed for c++, f77, and tk examples

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

On Monday 09 December 2002 17:11, Alan W. Irwin wrote:
| On Mon, 9 Dec 2002, [iso-8859-1] Jo=E3o Cardoso wrote:
| > On Monday 09 December 2002 06:04, Alan W. Irwin wrote:
| >
| > ...
| >
| > | > Lets see, if I (user/developper) have to install after make and
| > | > before use, in order to not disturb my system, I will install
| > | > in /usr/local/test. After everything looks fine, I will have to
| > | > configure/make/install again to install in the final place. Why
| > | > doesnt we install in the current location from the start? If we
| > | > like, we will configure/make/install to the final place, but
| > | > meanwhile we could evaluate/improve/debug in-place -- without
| > | > the mess of never exactly knowing if we are running the
| > | > installed or the just built library, as it recently happened
| > | > with you.
| > | >
| > | > Joao
| > |
| > | You should forget that e-mail from me.  It detailed what worked
| > | now and why. But I don't think that is the ultimate solution if
| > | you want to work more on this.
| > |
| > | Here is what I suggest.  Make a configuration option
| > | (enable-original-data or whatever better name you can come up
| > | with) that by default is disabled. However, when the user enables
| > | it, the code searchs for everything (drivers, fonts, tcl scripts)
| > | in the original location rather than the usual installed
| > | location. Our code would have to be changed to pay attention to
| > | this option, whenever searching for drivers, fonts, or tcl
| > | scripts, but at least with such an overall option it would be
| > | either one clear location or the other. The problem of searching
| > | both locations at once as in the old system is the behaviour
| > | depends on whether there was an old install around or not.  Most
| > | developers here have been caught by that problem with the old
| > | system.  At least with a configuration option the user has made a
| > | clear choice, and it is guaranteed (if you do the programming
| > | changes properly) that *only* one location (either original or
| > | installed but not both) will be searched.
| >
| > That is not the point that I want to discuss, but nevertheless I
| > don't quite agree. While your proposal makes sense, I think that we
| > could search in both locations, in the build tree and in the
| > install tree, as long as we search first in the build tree and
| > after that in the install tree. As long as we use relative adresses
| > when searching in the build tree, there is no risk that an user app
| > will end up using a build tree file.
| > This will simplify both the code and the configuration.

To make things clear: I just want to avoid the need to do a "make=20
install".

| I just want to be iron-clad guaranteed that we are getting the right
| data. Your idea of relative directory addresses should work to give
| us (nearly) this same guarantee, but the drawback is it means apps
| can only be executed in one directory level (either plplot/examples
| or its many subdirectories, but it could not be both.)

You are right here. But I think this should be discussed in another=20
thread, to no mix thinks like libraries and apps data. We control where=20
the data is.

| So I have a
| preference for adding a configuration option and using absolute
| directory addresses, but I could also live with no configuration
| option and the relative directory idea.  What do the other's think?
|
| > But that was not what I want to discuss.
| >
| > While apps. that use libraries can be fooled by libtool wrap
| > scripts, that search for libs in the libtools .libs directories and
| > in the install lib directory (that's why the c examples run OK even
| > if the install tree libraries don't exist), the same does not
| > happens for apps. that dlload modules (pluggins, as you call it in
| > another mail).
| >
| > For example, Octave loads plplot_octave.oct, but knows nothing
| > about plplot; the location of the libraries used by
| > plplot_octave.oct must be coded in plplot_octave.oct itself.
| > plplot_octave.oct can't be a libtool wrapper script, as Octave
| > expects to find a "module". I am pretty sure that the same happens
| > with python, tcl, perl and java.
|
| No. the python and tcl libraries are generated by libtool so there
| should be no problem there.

The problem is not how to generate libraries, but how/where will the=20
mother app (tcl or python) find them.
Anyhow, if you say that you will be able to run the tcl and python=20
examples *without* a "make install", then I will be happy. But in the=20
original post you said:

    "The python examples assume an installed location for the
     wrapper library, and the tcl and tk examples are even more
     dependent on installed data."

Again, I think that there is no problem for now if only data needs to be=20
installed. With "data" I *don't* mean the drivers. And yes, now I see,=20
the drivers are a good example to discuss this issue, because the=20
drivers are a kind of "extension modules" of plplot.

How do you intend to load the drivers without a "make install"? In the=20
installed directory, you can find a driver,
    /usr/local/test/lib/plplot5.1.0/drivers/xwin_drv.so

but in the build directory you only found=20
   drivers/xwin_drv.la
   drivers/xwin_drv_la-xwin.lo
   drivers/xwin_drv_la-xwin.o -> xwin_drv_la-xwin.lo

the real driver is in=20
   drivers/.libs/xwin_drv.la@
   drivers/.libs/xwin_drv.so*
   drivers/.libs/xwin_drv.lai
   drivers/.libs/xwin_drv.soT*

When the plplot library wants to load a driver, what will it look for?=20
xwin_drv.so, right? Or is that changed? That object can only be found at=20
the installed directoy or hidden in drivers/.libs.

Probably you will tell me that the plplot library is using libtool=20
dlopen, and that it will find the xwin_drv.so using xwin_drv.la. OK, it=20
works for our compiled examples, but *not* for pre-compiled apps.
Or I'm missing something?

Joao

Re: [Plplot-devel] "make check" support installed for c++, f77, and tk examples

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

On Mon, 9 Dec 2002, Alan W. Irwin wrote:

> So I do have definite plans to make sure the octave shared object is built
> with libtool just like the rest of our shared objects. But before I try any
> more octave changes I would like you to fix up the test scripts so the "x"
> examples work.  One thing at a time.

OOPS.  I subsequently learned that that ball is now in my court with Joao's
useful demonstation of the problem in C, but it is still one thing at a
time.

Alan

Re: [Plplot-devel] octave now configured with autotools

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

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

> As a matter of fact, if I add a plinit() at the end of main() in x01c.c,
> after plend() but before exit(), it has the same behaviour, it's not a
> octave issue:
>
> [jcard@feup] examples/c/x01c -dev xwin
> Plplot library version: 5.1.0
>
> Plotting Options:
> Segmentation fault

OK.  That is great that you got the problem "simplified" to the C front end=
=2E

I will look further into this.

Alan

Re: [Plplot-devel] "make check" support installed for c++, f77, and tk examples

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

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

> On Monday 09 December 2002 06:04, Alan W. Irwin wrote:
>
> ...
>
> | > Lets see, if I (user/developper) have to install after make and
> | > before use, in order to not disturb my system, I will install in
> | > /usr/local/test. After everything looks fine, I will have to
> | > configure/make/install again to install in the final place. Why
> | > doesnt we install in the current location from the start? If we
> | > like, we will configure/make/install to the final place, but
> | > meanwhile we could evaluate/improve/debug in-place -- without the
> | > mess of never exactly knowing if we are running the installed or
> | > the just built library, as it recently happened with you.
> | >
> | > Joao
> |
> | You should forget that e-mail from me.  It detailed what worked now
> | and why. But I don't think that is the ultimate solution if you want
> | to work more on this.
> |
> | Here is what I suggest.  Make a configuration option
> | (enable-original-data or whatever better name you can come up with)
> | that by default is disabled. However, when the user enables it, the
> | code searchs for everything (drivers, fonts, tcl scripts) in the
> | original location rather than the usual installed location. Our code
> | would have to be changed to pay attention to this option, whenever
> | searching for drivers, fonts, or tcl scripts, but at least with such
> | an overall option it would be either one clear location or the other.
> | The problem of searching both locations at once as in the old system
> | is the behaviour depends on whether there was an old install around
> | or not.  Most developers here have been caught by that problem with
> | the old system.  At least with a configuration option the user has
> | made a clear choice, and it is guaranteed (if you do the programming
> | changes properly) that *only* one location (either original or
> | installed but not both) will be searched.
>
> That is not the point that I want to discuss, but nevertheless I don't
> quite agree. While your proposal makes sense, I think that we could
> search in both locations, in the build tree and in the install tree, as
> long as we search first in the build tree and after that in the install
> tree. As long as we use relative adresses when searching in the build
> tree, there is no risk that an user app will end up using a build tree
> file.
> This will simplify both the code and the configuration.

I just want to be iron-clad guaranteed that we are getting the right data.
Your idea of relative directory addresses should work to give us (nearly)
this same guarantee, but the drawback is it means apps can only be executed
in one directory level (either plplot/examples or its many subdirectories,
but it could not be both.) So I have a preference for adding a configuratio=
n
option and using absolute directory addresses, but I could also live with n=
o
configuration option and the relative directory idea.  What do the other's
think?

>
> But that was not what I want to discuss.
>
> While apps. that use libraries can be fooled by libtool wrap scripts,
> that search for libs in the libtools .libs directories and in the
> install lib directory (that's why the c examples run OK even if the
> install tree libraries don't exist), the same does not happens for
> apps. that dlload modules (pluggins, as you call it in another mail).
>
> For example, Octave loads plplot_octave.oct, but knows nothing about
> plplot; the location of the libraries used by plplot_octave.oct must be
> coded in plplot_octave.oct itself. plplot_octave.oct can't be a libtool
> wrapper script, as Octave expects to find a "module". I am pretty sure
> that the same happens with python, tcl, perl and java.

No. the python and tcl libraries are generated by libtool so there should b=
e
no problem there.  Java is not done, but my plans are to generate that
library with libtool.  Same is true for perl (way down the road when perl i=
s
ready).  So the only odd one out is octave.  If it wasn't for their
strange suffix ".oct" I could do that with libtool as well (see below).

> To avoid using deep relative adresses, like ../../src/.libs, we could
> setup a lib directory in the build tree, and make symbolic links to the
> location of the real libraries.

I don't think that will be necessary since the octave library is the only
one with the problem at this point.  And if I can figure out a suffix issue
(see below), it won't be a problem for long.

>
> PS- the libtool info nodes adresses the issue of "dlopened modules", but
> it assumes that one has control over the app that will use the module,
> which is not the case, i.e., we don't have control how Octave loads
> plplot_octave.oct, nor how will python or perl load their plplot
> modules (language extensions, in the libtool parlance).

Let's concentrate on python and tcl since perl will only be relevant a long
time from now (unless somebody gets interested in it).  In both cases,
libtool builds the shared objects libplplottcltk.suffix and
plplotcmodule.suffix, where suffix ("so" on Linux) is appropriate to
whatever platform we are dealing with.  If you look at the tcl scripts ther=
e
is a mechanism there to load the plplot extension with a cross-platform way
to get the right suffix for the platform.  So that is an excellent match fo=
r
what libtool does.  I haven't looked at python in detail, but I assume thei=
r
import statement does something similar.  So that takes care of any naming
problems, and the internals are covered because libtool knows how to build
shared objects, which is all that is required for any language extension
including the python and tcl extensions.

Octave has taken a different approach.  Their mkoctfile script does all it
can to make a shared object in a cross-platform way.  Essentially, they are
trying to do libtool's job of building shared objects. However, they solved
the naming suffix problem by just using one, "oct".  Now I could do
everything mkoctfile does using libtool, but that suffix issue is the one
remaining problem. On Linux of course I could make a symlink between the
*.so result of libtool and *.oct, but I am still thinking about how to do
this in cross-platform way when that .so suffix could be anything.  I
believe the solution is to grep for dlname in the *.la file to find the
correct name to symlink to.

So I do have definite plans to make sure the octave shared object is built
with libtool just like the rest of our shared objects. But before I try any
more octave changes I would like you to fix up the test scripts so the "x"
examples work.  One thing at a time.

Alan

Re: [Plplot-devel] octave now configured with autotools

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

On Thursday 05 December 2002 03:56, Alan W. Irwin wrote:
| I have just committed some changes that should make octave work at
| least for some of the examples.
|
| I tested octave with the installed
| prefix/lib/plplot5.1.0/examples/plplot-test.sh script.

I tested in bindings/octave, after a "make install" and changing=20
=2Eoctaverc

| The early "p" examples work well, but p7.m and p15.m have problems.

p7.m had a bug (really shade.m), that I have already correct; p15.m runs=20
OK for me.

| Apparently, the p7.m problem is a long-standing one from comments in
| test_octave.sh, but the p15.m problem may be new.
|
| Also, I could not get any of the x??.m examples to work with that
| script. It only segfaults.  I presume plplot/test/test_octave.sh
| (which gets installed in prefix/lib/plplot5.1.0/examples/) needs to
| be adjusted to some change that has been made.

I don't think so. The problem arises if I plinit(), then plend() and=20
then plinit() again; at the second plinit() I get a seg. fault:

octave:1> plplot_stub=20
octave:2> plsdev("xwin")
octave:3> plinit
octave:4> plend
octave:5> plinit

Plotting Options:
 < 1> panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault

This does not happens in my frozen plplot directory (before AT merge),=20
so it is a consequence of the merge.

As a matter of fact, if I add a plinit() at the end of main() in x01c.c,=20
after plend() but before exit(), it has the same behaviour, it's not a=20
octave issue:

[jcard@feup] examples/c/x01c -dev xwin
Plplot library version: 5.1.0

Plotting Options:
Segmentation fault

Making the same modification on my frozen plplot dir just opens another=20
window, then exits without a seg. fault.

Joao

|
| After the early p examples worked, but the x examples segfaulted, I
| went back and looked at what was done before.  Apparently there is a
| sed step to replace PLPLOT_OCTAVE_PATH with the appropriate value in
| plplot_octave_path.m (see below).  I did that step by hand, but it
| didn't change either the early p examples working or x examples
| segfaulting.  So I think I have gone as far as I can go with this,
| and it is now up to Joao to smooth out these rough spots.
|
| Joao, I will be happy to answer any of your questions about what I
| did to configure octave with autotools.  But the overall changes that
| I did to (mostly) finish octave configuration were to create
| Makefile.am files (with appropriate automake information) in the
| directory tree under bindings/octave. automake takes care of the
| rest.  BTW, to do the equivalent of the sed substitution mentioned
| above in PLplot, I would suggest simply renaming plplot_octave_path.m
| as plplot_octave_path.m.in, putting an @xxx@ variable in the file,
| and changing configure.ac to configure xxx to whatever path you want.
|  Alternatively, you could stick with the sed method for editing
| plplot_octave_path.m.in to plplot_octave_path.m that automake will
| automatically install. You can stick that rule right in
| PLplot/Makefile.am, if you like. It is up to you which method you
| choose.
|
| Tomorrow, I plan to start working on the static devices.  I don't
| think that is going to take long at all. Rafael got them working
| earlier with the libtools convenience library approach, and I only
| plan a slight modification of his approach so that it doesn't clobber
| the dynamic driver approach. After that work is done, I will probably
| work on java.  That's really a low priority (since the API is so
| incomplete), and in fact I was planning to disable java for the
| release, but I have essentially run out of things to do before the
| release except cheer you guys on to sort out the remaining rough
| spots for PLplot.
|
| Currently, those rough spots consist of the -dev tk problem and the
| above octave problems. Also, we need lots of testing of this new
| configuration system both on Linux and also on other Unix platforms
| to find any other rough spots.  But that is about it....
|
| Alan
|
| email: ir...@be...
| phone: 250-727-2902=09FAX: 250-721-7715
| snail-mail:
| Dr. Alan W. Irwin
| Department of Physics and Astronomy,
| University of Victoria, P.O. Box 3055,
| Victoria, British Columbia, Canada, V8W 3P6
| __________________________
|
| Linux-powered astrophysics
| __________________________
|
|
|
| -------------------------------------------------------
| This SF.net email is sponsored by: Microsoft Visual Studio.NET
| comprehensive development tool, built to increase your
| productivity. Try a free online hosted session at:
| http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] "make check" support installed for c++, f77, and tk examples

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

On Monday 09 December 2002 06:04, Alan W. Irwin wrote:

=2E..

| > Lets see, if I (user/developper) have to install after make and
| > before use, in order to not disturb my system, I will install in
| > /usr/local/test. After everything looks fine, I will have to
| > configure/make/install again to install in the final place. Why
| > doesnt we install in the current location from the start? If we
| > like, we will configure/make/install to the final place, but
| > meanwhile we could evaluate/improve/debug in-place -- without the
| > mess of never exactly knowing if we are running the installed or
| > the just built library, as it recently happened with you.
| >
| > Joao
|
| You should forget that e-mail from me.  It detailed what worked now
| and why. But I don't think that is the ultimate solution if you want
| to work more on this.
|
| Here is what I suggest.  Make a configuration option
| (enable-original-data or whatever better name you can come up with)
| that by default is disabled. However, when the user enables it, the
| code searchs for everything (drivers, fonts, tcl scripts) in the
| original location rather than the usual installed location. Our code
| would have to be changed to pay attention to this option, whenever
| searching for drivers, fonts, or tcl scripts, but at least with such
| an overall option it would be either one clear location or the other.
| The problem of searching both locations at once as in the old system
| is the behaviour depends on whether there was an old install around
| or not.  Most developers here have been caught by that problem with
| the old system.  At least with a configuration option the user has
| made a clear choice, and it is guaranteed (if you do the programming
| changes properly) that *only* one location (either original or
| installed but not both) will be searched.

That is not the point that I want to discuss, but nevertheless I don't=20
quite agree. While your proposal makes sense, I think that we could=20
search in both locations, in the build tree and in the install tree, as=20
long as we search first in the build tree and after that in the install=20
tree. As long as we use relative adresses when searching in the build=20
tree, there is no risk that an user app will end up using a build tree=20
file.
This will simplify both the code and the configuration.

But that was not what I want to discuss.

While apps. that use libraries can be fooled by libtool wrap scripts,=20
that search for libs in the libtools .libs directories and in the=20
install lib directory (that's why the c examples run OK even if the=20
install tree libraries don't exist), the same does not happens for=20
apps. that dlload modules (pluggins, as you call it in another mail).

For example, Octave loads plplot_octave.oct, but knows nothing about=20
plplot; the location of the libraries used by plplot_octave.oct must be=20
coded in plplot_octave.oct itself. plplot_octave.oct can't be a libtool=20
wrapper script, as Octave expects to find a "module". I am pretty sure=20
that the same happens with python, tcl, perl and java.
In the old configuration scheme, plplot_octave was compiled twice, once=20
(a plain "make") specifying where libplplot.so was in the build tree,=20
and the other where libplplot.so was in the install tree (a "make=20
install").
I propose something similar now: a plain "make" would link apps against=20
the libraries located in the build tree; a "make install" would compile=20
(link) apps. against libraries in the install tree. i.e., I would turn=20
the current "make" into "make install", and create a new "make".

To avoid using deep relative adresses, like ../../src/.libs, we could=20
setup a lib directory in the build tree, and make symbolic links to the=20
location of the real libraries.

Joao

PS- the libtool info nodes adresses the issue of "dlopened modules", but=20
it assumes that one has control over the app that will use the module,=20
which is not the case, i.e., we don't have control how Octave loads=20
plplot_octave.oct, nor how will python or perl load their plplot=20
modules (language extensions, in the libtool parlance).

Joao

|
| Comments?
|
| Alan

[Plplot-devel] test, ignore.

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

Ignore, please

Joao

[Plplot-devel] Re: Symlink problem fixed

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

On Monday 09 December 2002 02:41, Alan W. Irwin wrote:
> Joao,
>
> Your present difficulties with symlinks on OSF1 are due to my mistake w=
hich
> I have just fixed with a bootstrap.sh commit.  Sorry!
>
> Once you update, then a ./bootstrap.sh in a *fresh checkout*
> will make copies of automake-related files rather than symlinks.  If yo=
u
> have an almost fresh checkout with just the old bootstrap.sh executed, =
then
> you must remove the symlinks before you execute (the new) bootstrap.sh
> again.

I'm using the -h option to tar; that's late here.
Meanwhile, configure has detected how to make shared libs in osf -- that =
were=20
not supported till AT!.
But configure fails:

   ...
   checking for python... no
   checking if Python version >=3D 1.5... configure: error: too old

configure should just set python to no instead of dying.

   ./configure --enable-dyndrivers --disable-python
   ...
   checking for python... no
   checking if Python version >=3D 1.5... configure: error: too old

same error!

Bye,
Joao

PS-if this message doesn't appears in the mailing list, could you please=20
forward it? Tomorrow I will see what is happening at the univ. mailler de=
amon=20
(i.e. call the sysop -:)


>
> There should be no symlinks in the tarball you create once you use the =
new
> bootstrap.sh procedure.  You can test for their presence in the tarball=
 by
> looking for the string "->" in the table of contents that you get by ta=
r
> ztvf ....
>
> Good luck, Joao, and let me know how it goes with your further testing =
of
> OSF1.
>
> 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] "make check" support installed for c++, f77, and tk examples

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

I am quoting Joao in full below because apparently he cannot reach the list
yet.  I have some comments at the end of my own.

Alan

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

Linux-powered astrophysics
__________________________

On Sun, 8 Dec 2002, Joao Cardoso wrote:

> On Friday 06 December 2002 18:22, Alan W. Irwin wrote:
> > make check now builds all non-installed examples fine, but the current
> > situation is you will need some data installed to actually use the
> > examples. Fonts and drivers are the only things requiring installation for
> > the c, c++, and f77 examples.  (I checked this by removing the installed
> > libraries, but nothing else).
>
> Yes, I checked it too. Fixing this will be easy, but I have some reservations
> on this.
>
> As an user, not developper, I often download/configure/make some packages,
> just to evaluate them. Often I just "rm -rf the thing", after evaluating it
> without installing. Till now very few packages couldn't be evaluated without
> installing. This will not be possible with plplot, at least with the
> interpreted bindings like python, tcl, octave and probably java.
>
> As a plplot user, I would download/configure/make the release to see if it is
> worth installing it. Only after evaluation. This will not be possible
> anymore.
>
> As a developper, I dont find practical the new scheme, at least for
> interpreted languages.
>
> Lets see, if I (user/developper) have to install after make and before use, in
> order to not disturb my system, I will install in /usr/local/test. After
> everything looks fine, I will have to configure/make/install again to install
> in the final place. Why doesnt we install in the current location from the
> start? If we like, we will configure/make/install to the final place, but
> meanwhile we could evaluate/improve/debug in-place -- without the mess of
> never exactly knowing if we are running the installed or the just built
> library, as it recently happened with you.
>
> Joao

You should forget that e-mail from me.  It detailed what worked now and why.
But I don't think that is the ultimate solution if you want to work more on
this.

Here is what I suggest.  Make a configuration option (enable-original-data
or whatever better name you can come up with) that by default is disabled.
However, when the user enables it, the code searchs for everything (drivers,
fonts, tcl scripts) in the original location rather than the usual installed
location. Our code would have to be changed to pay attention to this option,
whenever searching for drivers, fonts, or tcl scripts, but at least with
such an overall option it would be either one clear location or the other.
The problem of searching both locations at once as in the old system is the
behaviour depends on whether there was an old install around or not.  Most
developers here have been caught by that problem with the old system.  At
least with a configuration option the user has made a clear choice, and it
is guaranteed (if you do the programming changes properly) that *only* one
location (either original or installed but not both) will be searched.

Comments?

Alan

[Plplot-devel] Symlink problem fixed

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

Joao,

Your present difficulties with symlinks on OSF1 are due to my mistake which I
have just fixed with a bootstrap.sh commit.  Sorry!

Once you update, then a ./bootstrap.sh in a *fresh checkout*
will make copies of automake-related files rather than symlinks.  If you
have an almost fresh checkout with just the old bootstrap.sh executed, then
you must remove the symlinks before you execute (the new) bootstrap.sh
again.

There should be no symlinks in the tarball you create once you use the new
bootstrap.sh procedure.  You can test for their presence in the tarball by
looking for the string "->" in the table of contents that you get by tar
ztvf ....

Good luck, Joao, and let me know how it goes with your further testing of
OSF1.

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] (no subject)

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

Joao is having trouble getting mail to the list so I am forwarding this for
him.

___________________________________________________
I follow the receipt, and:


bash-2.01$ uname -a
OSF1 alf.fe.up.pt V4.0 1091 alpha
bash-2.01$ ./configure --enable-dyndrivers
No defaults file found, performing full configure.
No defaults file found, performing full configure.
No defaults file found, performing full configure.
configure: error: cannot find install-sh or install.sh in . ./.. ./../..
bash-2.01$ ls -l install-sh
lrwxrwxrwx   1 jcard    docentes      30 Dec  8 02:24 install-sh ->
/usr/share/automake/install-sh

In the linux box where I made the tarball (after cvs update . and
./bootstrap.sh)  works OK.

Joao
___________________________________________________

I will look into this further.  I believe there is a tar parameter to
actually put a file in the tarball rather than just leaving a symlink as
happened to Joao above.  But if I cannot get that to work, I can always try
to maintain "make dist" for a while.

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] Call for widespread testing of our new configuration scheme.

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

I have just committed a newly reorganized and updated PROBLEMS file which
details the essential issues that must be addressed before we release.  It
is a fairly long list, but the vast majority of the items will only take
a minor effort to solve.

The number one issue is cross-platform testing of the new autotools-based
configuration and building scheme.  We need tests of both the dynamic and
static driver cases.  Are there any Unix platforms where dynamic drivers
don't work?  If dynamic drivers work in a majority of cases, we should make
it the default.  But we won't know until we test.

The testing cookbook is given in
http://sourceforge.net/mailarchive/forum.php?thread_id=1375571&forum_id=2199.

Note that after a fresh checkout and the bootstrap.sh part (on Linux or
whatever Unix platform where autotools has been installed) you should be
able to make a tarball of your tree which you can unpack on *any* Unix
platform. The configure, make, and make install can be completed on that
"foreign" Unix platform without any autotools being installed.  This makes
cross-platform testing much easier than if you had to have autotools
installed on *every* platform you tested. Make the tarball directly from
your tree rather than using "make dist" because that latter choice is not
maintained (since it is a nightmare to do so).

Many on this list can help with this cross-platform testing effort of the
new configuration scheme so please do!  I have time to help you sort out any
problems you find over the next few weeks, but January 2nd my PLplot time is
going to be severely curtailed as I get involved in a new job so you will
be mostly on your own after that.

Alan

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

Linux-powered astrophysics
__________________________

[Plplot-devel] Linking solution for static drivers that has just been implemented is discussed. Rapid changes in new configuration scheme should now be over

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

I have just finished implementing the configuration of static drivers using
autotools.  The tough part was figuring out how I wanted to link everything
together (see below).  The easy part (couple of hours work) was implementing
my linking ideas using autotools.  Just to let you know that the autotools
effort has already more than paid off, that part would have been much more
difficult (= virtually impossible for someone with my skill set)
with the previous autoconf approach.

Here is the linking situation with dynamic drivers.  The arrows indicate the
linking direction that must occur in order to satisfy the undefined symbols
in a given library on the left.  Those symbols are resolved by referring to
the libraries on the right using the usual -l syntax during each library
link step.

(1) libplplottcltk ==> libplplot, libtclmatrix

(2) libtclmatrix ==>

(3) libplplotcxx ==> libplplot

(4) libplplotf77 ==> libplplot

(5) plplotc_module.so ==> libplplot

(6) libplplotjava ==> libplplot  (libplplotjava not done yet)

(7) libplplot ==>

(8) tk_drv.so ==> libplplottcltk

(9) tk_drv.so ==> libplplottcltk

(10) ps_drv.so ==> libplplot

This all works with dynamic drivers because libplplot dlopens the pre-linked
driver tk_drv.so (or tkwin_drv.so).  Also, libplplot is small which is an
advantage since that is the one most applications and libraries link to.
Also note that a tcl application only needs to link to libplplottcltk, and
everything else is automatically linked in as required.

However, with static linking you cannot naively use the same scheme since
you get a circular chain.  All driver codes are now put inside
libplplot.  That satisfies linking requirement for most drivers such as
ps_drv.so, but because of tk and tkwin we have

(7a) libplplot ==> libplplottcltk

which becomes circular with (1) which makes a mess.

Here is the solution I have implemented.  To cut the circular chain, I add
all the libplplottcltk and libtclmatrix objects into the convenience library
that also contains the static driver objects.  The configuration is set up
so that libtool automatically puts all the objects in the convenience
library into libplplot so libplplot ends up being self-contained as before
with no additional linking required to resolve its symbols (other than the
usual additional "driver" links to libraries such as libgd, etc.).  Of
course, libplplot is a little larger in this case, but those who use static
drivers on Unix machines get what they deserve.....

Note all other linking for the static drivers case is done as in the dynamic
drivers case which means that tcl executables can continue to get all their
symbols resolved and drivers found if they simply link to libplplottcltk as
before.  Similarly, normal non-tcl executables like x01c simply need to be
linked to libplplot as before.

I have tested these static drivers, and AFAIK they produce identical results
to the dynamic drivers case.  Dynamic loading under tclsh and wish still
works as before from the user perspective although internally an extra
search was implemented to find the initialization routines in the static
drivers case since those routines appear in a different shared object
location. Also, plrender, and pltcl work fine.

The "works as in the dynamic driver case" also extends to -dev tk not
working in exactly the same way.  Since the library linking of the driver is
quite changed, I believe this problem is something fundamental which has
nothing to do with linking.

I declare the current phase of rapid changes to our configuration as
officially over.  From now on, I expect to see considerably more gradual
changes as the cross-platform tests start rolling in.

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] "make check" support installed for c++, f77, and tk examples

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

make check now builds all non-installed examples fine, but the current
situation is you will need some data installed to actually use the examples.
Fonts and drivers are the only things requiring installation for the c, c++,
and f77 examples.  (I checked this by removing the installed libraries, but
nothing else).  The python examples assume an installed location for the
wrapper library, and the tcl and tk examples are even more dependent on
installed data.

Bottom line: use make install *once* before make check, but from then on a
debugging cycle for routines in libplplot, libplplotf77, or libplplotcxx or
the c, c++, or fortran examples should be very quick.  make install once
before debugging python or tcl scripts locally should also work fine unless
the problem you are debugging is in one of the libplplot libraries or the
installed tcl scripts.  If it is a library problem you are debugging, it is
probably best to use the c, f77, or c++ examples for debugging in any case.
If you are debugging installed tcl scripts, use make install every debug
cycle, but you can significantly speed that step up (currently ~20s on my
600MHz class machine with all drivers enabled) by eliminating all drivers
you don't need.

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] Sub-library names and static drivers progress

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

Alan W. Irwin writes:
 > Since every user's link step is going to be changed in any case with the new
 > linking scheme, I took this opportunity to change the C++ library name from
 > libplcxx to libplplotcxx.  The only really unique thing about libplcxx is
 > the "pl", and I was concerned that eventually by random accident some other
 > package would also attempt to claim that name which would result in a mess.
 > 
 > For similar reasons, I have named the new fortran library libplplotf77.

Both of these choices sound good to me.

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

[Plplot-devel] Sub-library names and static drivers progress

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

Since every user's link step is going to be changed in any case with the new
linking scheme, I took this opportunity to change the C++ library name from
libplcxx to libplplotcxx.  The only really unique thing about libplcxx is
the "pl", and I was concerned that eventually by random accident some other
package would also attempt to claim that name which would result in a mess.

For similar reasons, I have named the new fortran library libplplotf77.

On the static drivers front, I have been doing a lot of thinking today about
the best way to do it. The problem is that all the hierarchical links, and
what libraries have to be created first are turned inside out and backside
front by the tk driver.  However, I believe I have just now come up with a
solution which I will attempt to implement tonight.

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
__________________________