plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

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

> Pretty sure, I had to cvs update to see your changes. The configure line
> after upgrading to the last autools versions and running bootstrap.sh:
>
> > make maintainer-clean
> > ./bootstrap.sh
> Running aclocal (GNU automake) 1.7.2... done
> Running libtoolize (GNU libtool) 1.4.3... done
> Running autoheader (GNU Autoconf) 2.57... done
> Running automake (GNU automake) 1.7.2... done
> Running autoconf (GNU Autoconf) 2.57... done
> > ./configure --enable-octave --enable-dyndrivers --disable-static
>  --with-double --prefix=3D/usr/local/test

I confirm the segfault problem found by Joao:

I just did an absolutely fresh checkout from cvs, rm -rf $prefix/*;
=2E/bootstrap.sh; configure (followed Joao's configure options of
--enable-octave --enable-dyndrivers --disable-static --with-double ); make;
make install; cd $prefix/lib/plplot-5.2.0/examples/c; make

Then ./x01c -dev xwin

produces a segfault.  In fact if you ./x01c with no options or the -debug
option there is an immediate segfault with no output whatsoever.

I then used valgrind ./x01c and there are an enormous number of messages (n=
ot
there before) involving invalid reads, etc.  So there is clearly a memory
management problem with the new code.

Rafael, you should be able to reproduce this bug if you do exactly what I
did since we have very similar systems.  Joao's choice of configure options
may be important or there may be something left over in your build or
install location that makes it work on your system but not on ours. But the
fresh checkout and the above rm -rf should take care of that potential
difference between us.

Once you confirm the bug, I highly recommend

valgrind --gdb-attach=3Dyes --num-callers=3D100 ./x01c

to quickly debug the memory management problem.

Good luck!

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] New way of getting device info from dyndrivers

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

On Wednesday 05 February 2003 17:15, Rafael Laboissiere wrote:
| * Jo=E3o Cardoso <jc...@fe...> [2003-02-05 16:55]:
| > I decided to give it a try but got a seg fault:
| >
| > [jcard@feup] gdb x01c
|
| Well, all the 20 demos run fine for me.
|
| > (gdb) run -dev xwin
| > Starting program: /usr/local/test/lib/plplot5.2.0/examples/c/x01c
| > -dev xwin
| >
| > Program received signal SIGSEGV, Segmentation fault.
| > 0x0806a46e in lt_dlsym (handle=3D0x807b0e0,
| >     symbol=3D0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
| > [...]
|
| That is very strange.  Are you sure that you have the newest cvs
| sources?

Pretty sure, I had to cvs update to see your changes. The configure line=20
after upgrading to the last autools versions and running bootstrap.sh:

> make maintainer-clean
> ./bootstrap.sh=20
Running aclocal (GNU automake) 1.7.2... done
Running libtoolize (GNU libtool) 1.4.3... done
Running autoheader (GNU Autoconf) 2.57... done
Running automake (GNU automake) 1.7.2... done
Running autoconf (GNU Autoconf) 2.57... done
> ./configure --enable-octave --enable-dyndrivers --disable-static
 --with-double --prefix=3D/usr/local/test

Joao

Re: [Plplot-devel] library version

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

On Wednesday 05 February 2003 17:17, Alan W. Irwin wrote:
| On Wed, 5 Feb 2003, Rafael Laboissiere wrote:
| > I have a mission on earth: to avoid propagation of misunderstanding
| > of the purpose of library versioning.  Please, help me to achieve
| > that :-)
|
| I am going to take this discussion to the list.
|
| I asked for library version discussion before the 5.2.0 release, but
| nobody cared at the time.  So I think all of us will probably go
| along with whatever you decide. Note, I don't want to be involved in
| the decision making on library version because I don't have the time
| to keep track of what kind of API change occurred since the last
| release for each and every library.  I know that is sloppy, but I am
| already too overloaded with PLplot stuff.
|
| If you decide to go forward with this change, you should remember
| libtclmatrix is completely independent so it potentially should have
| independent version numbers. I am not sure whether our other
| libraries should have common version numbers or not, but you should
| check that.

I think they must, as they reflect the main library API.

|  If you decide to keep track of the API changes for each
| library, I presume you should make a decision about library version
| numbers for each library and commit that result roughly a week before
| release.  I would definitely welcome your effort on this, but if you
| don't have time for that, I fully understand because I don't have
| time for it myself....;-)

I don't have the original e-mail, but isn't enought to watch if plplot.h=20
has changed from the last release, and if yes just look at the loged=20
messages? API changes are generally well documented, and we could=20
enforce this, requiring that the log message includes the text "API=20
change".

| An alternative to the maintenance effort of keeping track of all API
| changes for each library is we could always blindly increment the
| major library version number for each and every release.

That would simplify our work, sure, just to complicate users work, as=20
they have to recompile all theirs apps each time they upgrade.
Till now, they don't have to recompile; if suddendly an app stops=20
working, then the user will remember "ah, I have upgraded plplot, lets=20
recompile".

|  That is
| roughly compatible with reality which is there is always some API
| change for most releases.

I have just now looked at the log messages since 5.0.1 and it is clear=20
at a first look that the library should have changed version for each=20
release.

Joao

| The only downside I can see of blind major
| number incrementing is we may soon get to library versions in the
| teens or even in the twenties, but at some point I am sure it is
| possible to recycle again and start back at the minimum library
| number (1.0.0?).  In fact, as far as I am concerned, we could start
| at the minimum library version number for the next release to
| emphasize the point that it is different from the package version.
|
| 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
| __________________________
|
|
|
| -------------------------------------------------------
| This SF.NET email is sponsored by:
| SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
| http://www.vasoftware.com
| _______________________________________________
| Plplot-devel mailing list
| Plp...@li...
| https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* Maurice LeBrun <mj...@ga...> [2003-02-05 14:05]:

> Rafael Laboissiere writes:
>  > * Maurice LeBrun <mj...@ga...> [2003-02-05 12:25]:
>  > 
>  > > If you are introducing variables into the global name space (i.e.
>  > > accessible via "extern"), at least give them a plplot-specific introducer
>  > > like "pl_" or even better "pldev_".
>  > 
>  > Point taken.  
>  > 
>  > The functions exported by the the drivers have the "plD_" prefix.  Would
>  > that be appropriate?  Should I use something like: plD_DESCRIPTION_<dev>
>  > with the variable name in upper case to emphasize the fact that they are
>  > exported variables?
> 
> Sure.

I just committed the change for the extern DEVICE_INFO_<driver> variables.
They are called now plD_DEVICE_INFO_<driver>.
 
-- 
Rafael

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

Rafael Laboissiere writes:
 > * Maurice LeBrun <mj...@ga...> [2003-02-05 12:25]:
 > 
 > > If you are introducing variables into the global name space (i.e.
 > > accessible via "extern"), at least give them a plplot-specific introducer
 > > like "pl_" or even better "pldev_".
 > 
 > Point taken.  
 > 
 > The functions exported by the the drivers have the "plD_" prefix.  Would
 > that be appropriate?  Should I use something like: plD_DESCRIPTION_<dev>
 > with the variable name in upper case to emphasize the fact that they are
 > exported variables?

Sure.

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

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* Maurice LeBrun <mj...@ga...> [2003-02-05 12:25]:

> If you are introducing variables into the global name space (i.e.
> accessible via "extern"), at least give them a plplot-specific introducer
> like "pl_" or even better "pldev_".

Point taken.  

The functions exported by the the drivers have the "plD_" prefix.  Would
that be appropriate?  Should I use something like: plD_DESCRIPTION_<dev>
with the variable name in upper case to emphasize the fact that they are
exported variables?
 
-- 
Rafael

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

Rafael Laboissiere writes:
 > * Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]:
 > 
 > >    c) At build time (not configuration time), a small C program dlopen the
 > >       <driver>.c files, get the symbols described above and write the
 > >       associated device entries in <driver>.rc (or whichever name).
 > 
 > Just to make things a bit more concrete, here is the design that I have in
 > mind.  I will take the ps.c driver as an example.  The following global
 > variables will be defined in the driver source:
 > 
 >     char* DEVICES_ps      = "ps:psc";
 > 
 >     char* DESCRIPTION_ps  = "PostScript File (monochrome)";
 >     int   TYPE_ps         = plDevType_FileOriented;
 >     int   SEQNUM_ps       = 29;
 >     char* SYMTAG_ps       = "psm";
 >     
 >     char* DESCRIPTION_psc = "PostScript File (color)";
 >     int   TYPE_psc        = plDevType_FileOriented;
 >     int   SEQNUM_psc      = 30;
 >     char* SYMTAG_psc      = "psc";
 > ...
 > What do you think?  I accept suggestions for better variable names.

If you are introducing variables into the global name space (i.e. accessible
via "extern"), at least give them a plplot-specific introducer like "pl_" or
even better "pldev_".

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

[Plplot-devel] Re: Problems Installing Plplot-5.2.0 under AIX (fwd)

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

It appears from the ./x01c -debug message below that dynamic drivers do not
work at all on AIX.  The error reminds me very much of what happened with
OSF1 when Joao first tested it.  Ultimately, we overcame that by being very
careful of the exact file name root we asked for with lt_dlopenext so that
it could try various suffixes for each platform until something worked.  (I
have already cautioned Rafael about that issue with his new scheme.)
However, it appears from the -debug message below that even lt_dlopenext
cannot find the correct AIX driver file at this time.

The good news is that Don was finally successful on AIX with plplot-5.2.0 if
he used static drivers (without double) and avoided C++, f77, and tcl.
There was one minor issue with the bindings/octave/Makefile which I am still
tracking down (I think some of my comments mixed in with rules are giving
problems to AIX make), but he bypassed that with make -k install.

If Don is still willing to do some further testing, I think we have a good
chance of solving the bindings/octave/Makefile issue and possibly (depending
on ongoing discussions with Maurice) also the tcl issue before 5.2.1.

The dynamic drivers and c++ and f77 issues will probably have to wait.

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
__________________________

---------- Forwarded message ----------
Date: Wed, 05 Feb 2003 09:53:54 -0500
From: Don Spong <sp...@or...>
To: Alan W. Irwin <ir...@be...>
Subject: Re: Problems Installing Plplot-5.2.0 under AIX

Alan,

You asked about the following:

>To give me some additional information about this error, please
>try
>
>./x01c -debug -dev xwin

Okay, here's what I got:

spongda>x01c -debug -dev xwin
Plplot library version: 5.2.0
plLoadDriver: Device not loaded!
plLoadDriver: tag=xw, drvidx=11
plLoadDriver: Trying to load xwin_drv on
/home/spongda/plplot_install_dir_5.2.0/lib/plplot5.2.0/data/../drivers/xwin_drv
plLoadDriver: lt_dlopenext failed because of the following reason:
file not found
Unable to load driver: xwin_drv.

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

x01c now works okay when I build with static drivers.

_________________________________________________________
Donald A. Spong, Fusion Energy Theory, ORNL
Snail-mail: P. O. Box 2009
Oak Ridge, Tennessee  37831-8071
Phone: (865) 574-1304   FAX: (865) 576-7926
E-mail: sp...@or...
web page: http://www.ornl.gov/fed/Theory/stci/stellarator_theory.html
_________________________________________________________

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* João Cardoso <jc...@fe...> [2003-02-05 16:55]:

> I decided to give it a try but got a seg fault:
> 
> [jcard@feup] gdb x01c

Well, all the 20 demos run fine for me.

> (gdb) run -dev xwin
> Starting program: /usr/local/test/lib/plplot5.2.0/examples/c/x01c -dev 
> xwin
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0806a46e in lt_dlsym (handle=0x807b0e0, 
>     symbol=0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
> [...]

That is very strange.  Are you sure that you have the newest cvs sources?

-- 
Rafael

[Plplot-devel] library version

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

On Wed, 5 Feb 2003, Rafael Laboissiere wrote:

> I have a mission on earth: to avoid propagation of misunderstanding of the
> purpose of library versioning.  Please, help me to achieve that :-)
>

I am going to take this discussion to the list.

I asked for library version discussion before the 5.2.0 release, but nobody
cared at the time.  So I think all of us will probably go along with
whatever you decide. Note, I don't want to be involved in the decision
making on library version because I don't have the time to keep track of
what kind of API change occurred since the last release for each and every
library.  I know that is sloppy, but I am already too overloaded with PLplot
stuff.

If you decide to go forward with this change, you should remember
libtclmatrix is completely independent so it potentially should have
independent version numbers. I am not sure whether our other libraries
should have common version numbers or not, but you should check that.  If
you decide to keep track of the API changes for each library, I presume you
should make a decision about library version numbers for each library and
commit that result roughly a week before release.  I would definitely
welcome your effort on this, but if you don't have time for that, I fully
understand because I don't have time for it myself....;-)

An alternative to the maintenance effort of keeping track of all API changes
for each library is we could always blindly increment the major library
version number for each and every release.  That is roughly compatible with
reality which is there is always some API change for most releases. The only
downside I can see of blind major number incrementing is we may soon get to
library versions in the teens or even in the twenties, but at some point I
am sure it is possible to recycle again and start back at the minimum
library number (1.0.0?).  In fact, as far as I am concerned, we could start
at the minimum library version number for the next release to emphasize the
point that it is different from the package version.

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] New way of getting device info from dyndrivers

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

On Wednesday 05 February 2003 13:55, Rafael Laboissiere wrote:
| * Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]:
| >    c) At build time (not configuration time), a small C program
| > dlopen the <driver>.c files, get the symbols described above and
| > write the associated device entries in <driver>.rc (or whichever
| > name).
|
| Just to make things a bit more concrete, here is the design that I
| have in mind.  I will take the ps.c driver as an example.  The
| following global variables will be defined in the driver source:
|
|     char* DEVICES_ps      =3D "ps:psc";
|
|     char* DESCRIPTION_ps  =3D "PostScript File (monochrome)";
|     int   TYPE_ps         =3D plDevType_FileOriented;
|     int   SEQNUM_ps       =3D 29;
|     char* SYMTAG_ps       =3D "psm";
|
|     char* DESCRIPTION_psc =3D "PostScript File (color)";
|     int   TYPE_psc        =3D plDevType_FileOriented;
|     int   SEQNUM_psc      =3D 30;
|     char* SYMTAG_psc      =3D "psc";
|
| Of course, these variables should be used in the plD_dispatch_init_*
| functions.  In the case of ps.c:
|
|     ps_dispatch_init_helper( pdt,
|                              DESCRIPTION_ps, "ps",
|                              TYPE_ps, SEQNUM_ps,
|                              (plD_init_fp) plD_init_psm );
|
|     ps_dispatch_init_helper( pdt,
|                              DESCRIPTION_psc, "psc",
|                              TYPE_psc, SEQNUM_psc,
|                              (plD_init_fp) plD_init_psc );
|
| This will insure that things are not defined twice in different
| places (like with the current DEVICE_INFO_* variable).
|
| The small C program that will generate the <driver>.rc file from the
| <driver>.la file, would do: (1) dlopen the module; (2) get the
| DEVICES_* symbol and parse its device components (in the ps.c
| exemple, that would be "ps" and "psc"); (3) for each one of the
| devices found, get the symbols DESCRIPTION_<dev>, TYPE_<dev>,
| SEQNUM_<dev>, and SYMTAG_<dev>; (4) create the temp file that is
| parsed by Geoff's code. (This could be improved along Joao's
| suggestion of creating a structure instead of writing the information
| in a temp file.)
|
| We have to decide first whether it is not worth abandoning the
| current approach and adopting this "cached info" approach above.=20

I decided to give it a try but got a seg fault:

[jcard@feup] gdb x01c
(gdb) run -dev xwin
Starting program: /usr/local/test/lib/plplot5.2.0/examples/c/x01c -dev=20
xwin

Program received signal SIGSEGV, Segmentation fault.
0x0806a46e in lt_dlsym (handle=3D0x807b0e0,=20
    symbol=3D0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
3330      lensym =3D LT_STRLEN (symbol) + LT_STRLEN=20
(handle->loader->sym_prefix)
(gdb) where
#0  0x0806a46e in lt_dlsym (handle=3D0x807b0e0,=20
    symbol=3D0xbfffef50 "DEVICE_INFO_pstex") at ltdl.c:3330
#1  0x08053d38 in plInitDispatchTable () at plcore.c:1638
#2  0x08049b9d in plMergeOpts (options=3D0x8073500,=20
    name=3D0x11 <Address 0x11 out of bounds>, notes=3D0x11) at plargs.c:6=
99
#3  0x08049362 in main ()
#4  0x400674a2 in __libc_start_main () from /lib/libc.so.6


| There is also Joao's suggestion for dynamically building the
| drivers.db, but I am too lazy to implement that (and I am not sure it
| is a superior approach).
|
| What do you think?  I accept suggestions for better variable names.

Re: [Plplot-devel] Tests of recent commits

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

On Monday 03 February 2003 22:17, Alan W. Irwin wrote:
| On Mon, 3 Feb 2003, Rafael Laboissiere wrote:
| > > make[3]: Entering directory `/home/jcard/plplot/bindings/python'
| > > python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
| > > plplotcmodule.i
| > > Unknown option: -o
| >
| > No idea about this.  Alan?
|
| The command should be
|
| $(SWIG) -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
|         plplotcmodule.i
|
| So I think his error message is caused because $(SWIG) is undefined
| for him, but I don't know the root cause of that problem. One
| possibility is the old autotools versions he is using. Another
| possibility is he may have forgot to specify --enable-maintainer-mode
| for his ./configure option.  I don't know whether that is essential
| or not after you have done a make
| maintainer-clean, but I suspect it is.
|
| What happens, Joao, for the latest stable autotools versions, clean
| PLplot checkout, and --enable-maintainer-mode?

Now everything runs OK:

> make maintainer-clean

> ./bootstrap.sh=20
Running aclocal (GNU automake) 1.7.2... done
Running libtoolize (GNU libtool) 1.4.3... done
Running autoheader (GNU Autoconf) 2.57... done
Running automake (GNU automake) 1.7.2... done
Running autoconf (GNU Autoconf) 2.57... done

> ./configure *without* the --enable-maintainer-mode
=2E..
make[3]: Entering directory `/home/jcard/plplot/bindings/python'
swig -python -o plplotcmodule_p_double.c -c++ -DPL_DOUBLE \
=2E..

Joao

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

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

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

> On Wednesday 05 February 2003 11:25, Rafael Laboissiere wrote:
> | Update of /cvsroot/plplot/plplot/drivers
> | In directory sc8-pr-cvs1:/tmp/cvs-serv16366/drivers
> |
> | Modified Files:
> | 	Makefile.am pstex.c
> | Log Message:
> | Cleaned up the ps vs. pstex driver mess.  When dyndrivers are
> | enabled, the use of --enable-pstex imply now the inclusion of the
> | ps.so driver module, enabling the ps and psc devices.
> |
> | On the other hand, when --enable-ps and --diasable-pstex are
> | specified, the pstex.so driver module is not erroneously installed,
> | as it used to be.
> 
> BTW, this does not also happens with the xwin and tk driver? If I 
> disable xwin but enable the tk driver (not very likely), than the tk 
> driver will not work, as it needs xwin. The reverse works fine.

Yes, a similar change has to be done for enable_tk and enable_xwin.  Since I
never use Tcl/Tk, I let fix this to the others.

(Well, I never use pstex neither, but I do not feel myself comfortable in
making changes to the Tcl/Tk part of PLplot.)

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

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

[Errata.  I am typing too fast...]

* Rafael Laboissiere <lab...@ps...> [2003-02-05 16:19]:

> drivers claim the same number, of of them will (randomly) get first in the
                                 ^^
*one* of them

> This is way I see this sequence number as a kind of "priority level".
          ^^^

*why*	  
 
-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

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

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

> I assume you are talking about your new code here.  For the old code the
> numbers had to be unique

Not necessarily.  In the old code, the entries were sorted using the seq
filed of the PLDispatchtable entries using qsort.  This means that, when two
drivers claim the same number, of of them will (randomly) get first in the
list.  However, it is guaranteed that they will appear both before (above)
drivers with greater (lesser) sequence numbers.

This is way I see this sequence number as a kind of "priority level".

> (and seqnum was 6 for the gnome driver).

Right, I thought I had put "1" in the past.

> Of course, that was a maintenance burden so if they just become non-unique
> priority numbers now, that is a significant improvement.

This is exactly the idea behind my last proposal.

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

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

On Wed, 5 Feb 2003, Rafael Laboissiere wrote:

> > Also, with the second idea I think that the driver-ids (the magic numbers)
> > can go away -- ah, no, for historical reasons the xwin driver must be
> > number one, the tk driver number 2, etc. hmm, there is another solution for
> > this but let discuss it latter.
>
> Please, notice that these magic number (seqnum) are not so "magic".  They
> only give a hint about how to order them.  Think on them like "priority
> level". BTW, the gnome driver also has seqnum = 1.

I assume you are talking about your new code here.  For the old code the
numbers had to be unique (and seqnum was 6 for the gnome driver).  Of course,
that was a maintenance burden so if they just become non-unique priority
numbers now, that is a significant improvement.

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] New way of getting device info from dyndrivers

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

On Wed, 5 Feb 2003, Maurice LeBrun wrote:

> I say move it (plbuf.c).  [...] Be sure to mention where it came from & what version
> in the first commit of the file in the new location.

Done.

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] New way of getting device info from dyndrivers

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

* Rafael Laboissiere <lab...@ps...> [2003-02-04 22:37]:

>    c) At build time (not configuration time), a small C program dlopen the
>       <driver>.c files, get the symbols described above and write the
>       associated device entries in <driver>.rc (or whichever name).

Just to make things a bit more concrete, here is the design that I have in
mind.  I will take the ps.c driver as an example.  The following global
variables will be defined in the driver source:

    char* DEVICES_ps      = "ps:psc";

    char* DESCRIPTION_ps  = "PostScript File (monochrome)";
    int   TYPE_ps         = plDevType_FileOriented;
    int   SEQNUM_ps       = 29;
    char* SYMTAG_ps       = "psm";
    
    char* DESCRIPTION_psc = "PostScript File (color)";
    int   TYPE_psc        = plDevType_FileOriented;
    int   SEQNUM_psc      = 30;
    char* SYMTAG_psc      = "psc";
    
Of course, these variables should be used in the plD_dispatch_init_*
functions.  In the case of ps.c:

    ps_dispatch_init_helper( pdt,
                             DESCRIPTION_ps, "ps",
                             TYPE_ps, SEQNUM_ps,
                             (plD_init_fp) plD_init_psm );

    ps_dispatch_init_helper( pdt,
                             DESCRIPTION_psc, "psc",
                             TYPE_psc, SEQNUM_psc,
                             (plD_init_fp) plD_init_psc );

This will insure that things are not defined twice in different places (like
with the current DEVICE_INFO_* variable).

The small C program that will generate the <driver>.rc file from the
<driver>.la file, would do: (1) dlopen the module; (2) get the DEVICES_*
symbol and parse its device components (in the ps.c exemple, that would be
"ps" and "psc"); (3) for each one of the devices found, get the symbols
DESCRIPTION_<dev>, TYPE_<dev>, SEQNUM_<dev>, and SYMTAG_<dev>; (4) create
the temp file that is parsed by Geoff's code. (This could be improved along
Joao's suggestion of creating a structure instead of writing the information
in a temp file.)

We have to decide first whether it is not worth abandoning the current
approach and adopting this "cached info" approach above.  There is also
Joao's suggestion for dynamically building the drivers.db, but I am too lazy
to implement that (and I am not sure it is a superior approach).

What do you think?  I accept suggestions for better variable names.

-- 
Rafael

Re: [Plplot-devel] Re: New way of getting device info from dyndrivers

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

* Rafael Laboissiere <lab...@ps...> [2003-02-05 12:23]:

>     drivers_DATA = $(drivers_LTLIBRARIES:.la=.rc)
>     %.rc: %.la get_drv_info
>             @echo get_drv_info $< $@

Please, take that "@echo" out.  I used it for testing the idea here.
It works, anyway.

I guess I am typing too fast and posting without reading what I wrote...

-- 
Rafael

[Plplot-devel] Re: New way of getting device info from dyndrivers

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

[ Sorry if this message is duplicated.  I sent it originally to Joao only and
  tried to bounce it from my MUA.  Since I did not receive it from the
  listserver, I am trying again, as a forward.

  BTW, why are the plplot-devel archives @ SF not accessible?]


* Joao Cardoso <jc...@fe...> [2003-02-05 02:53]:

> That's true, but the target should be to get a full-working 5.2.1, that
> should be, in my opinion, a bug-correcting release. Introducing such stuff
> can compromise it. But we have not defined what 5.2.1 should be, and I'm
> too conservative.

Well, my changes does not introduce new features to PLplot.  BTW, they are
transparent for the users and only slightly important for the developers
(actually, I think my changes improve maintainability).

> I have myself lots of new stuff, and I'm refraining myself to commit them.
> I hope that 5.2.2 or even 5.3.0 follows shortly.

If you are planning to do changes that will either destabilize the code or
introduce new features like changes in the API, I think you should refrain
yourself until 5.2.1 is out.

> Ah, you use a tmp file just to reuse Geoff's code. But there is no reason to 
> not change that also latter, right?

You got it.  I have not against improving the code and putting all the
information in a structure, that can also be cached in the <driver>.rc
files.  The important point here is that we should not have a unique file
(like drivers.db) that contains the information about all available drivers.

> > 1) Portability.  I am using new libc functions (POSIX tmpfile, opendir,
> >    readdir and closedir).  Although am I following the recommended
> > procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a
> > couple of tests with HAVE_DIRENT_H), I am sure that there will be some
> > weird system out there (MacIntosh, say) for which my code won't compile. 
> > If that happens, we have to port that part of the code.
> 
> Don't create the file :)

>From the smile, I guess you are joking.  I did not get the joke, though...

> >    c) At build time (not configuration time), a small C program dlopen the
> >       <driver>.c files,
> 
> You mean "open" and not dlopen(), right?

No, I meant dlopen (lt_dlopenext, to be more precise).

> No, you mean dlopen() the <driver>.so (I don't know the current suffix)

Yes, I mistakenly wrote <driver>.c.

> I prefer the full dynamic one, i.e., reading the already build drivers. I 
> don't think that performance will suffer.

It is not only a matter of time performance, but I was wondering about hte
fact that when all the module are dynamically loaded, all the libraries
(tcl, gd, gnome, etc.) will be unnecessarily dynamically linked.  I am just
specutlating about this, though.

> Do you have some figures or only feelings?

I have no figures, but my feeling is that it does not affect performance at
all.  I have here:

    $ cat /proc/cpuinfo | egrep "^(model n|cpu M|bogo)"
    model name      : Pentium III (Coppermine)
    cpu MHz         : 929.842
    bogomips        : 1854.66


> Your second idea implies that the small program that scans the source files
> [..]

No, it would "scan" the <driver>.la files (see above).

> [...] needs information from the configure step to know what drivers are
> desired by the user and supported by the system. This complicates matters.

Yes, the list of dynamic drivers is built at configure time and stored in
the variable DYNAMIC_DRIVERS, which is passed to drivers/Makefile.am.  
However, there will no further complication in the build process.  The
following addition to drivers/Makefile.am should do the job:

    drivers_DATA = $(drivers_LTLIBRARIES:.la=.rc)
    %.rc: %.la get_drv_info
            @echo get_drv_info $< $@

Where the get_drv_info.c is the C program that I mentioned already.	    
	
> With the first idea, by contrary, only already build drivers, i.e, user
> desired and system supported, are scanned.

If there is no drawback with this solution, I will adopt it (it is in CVS
already).  However, I would prefer a "info cached" approach.

> Also, with the second idea I think that the driver-ids (the magic numbers)
> can go away -- ah, no, for historical reasons the xwin driver must be
> number one, the tk driver number 2, etc. hmm, there is another solution for
> this but let discuss it latter.

Please, notice that these magic number (seqnum) are not so "magic".  They
only give a hint about how to order them.  Think on them like "priority
level". BTW, the gnome driver also has seqnum = 1.

> If performance is really an issue, then one could implements a mixing of
> the two ideas: don't generate drivers.db at configure nor build time. At
> run time if drivers.db does not exists, scan the drivers and build it. This
> way the performance loss will only occurs once. If a new driver is latter
> added to the directory (not probable, but possible, after all this is the
> only advantage of dyndrivers), one could first compare the time-stamp of
> all drivers versus the drivers.db file, and rebuild drivers.db if a driver
> is more recent. Reading time-stamp is fast, I believe.

This is a nice possibility, it is maybe the best solution, but someone has
to implement it.  It adds complexity to the code.  Volunteers? ;-)

-- 
Rafael

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* Joao Cardoso <jc...@fe...> [2003-02-05 02:09]:

> No. I only remember that the pstex configuration changed a couple of times.
> The pstex needs the ps driver, directly calling the ps driver entry points.
> 
> If it works with Rafael changes, that's fine for me. For a quick test use
> any C example and the scripts/pstex2eps script to generate an eps.

I cleaned up this mess, see my last cvs commit.  For dyndrivers, it
seems that when pstex.so is dynopened, ps.so must be also be present in the
drivers directory.  I added the following lines to configure.ac:

if test "$enable_dyndrivers" = yes -a "$enable_pstex" = yes ; then
  enable_ps=yes
fi

I also fixed the dependencies in drivers/Makefile.am and changed "ps" to
"pstex" in DEVICE_INFO_pstex (pstex.c file).

-- 
Rafael

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* Joao Cardoso <jc...@fe...> [2003-02-05 02:53]:

> That's true, but the target should be to get a full-working 5.2.1, that
> should be, in my opinion, a bug-correcting release. Introducing such stuff
> can compromise it. But we have not defined what 5.2.1 should be, and I'm
> too conservative.

Well, my changes does not introduce new features to PLplot.  BTW, they are
transparent for the users and only slightly important for the developers
(actually, I think my changes improve maintainability).

> I have myself lots of new stuff, and I'm refraining myself to commit them.
> I hope that 5.2.2 or even 5.3.0 follows shortly.

If you are planning to do changes that will either destabilize the code or
introduce new features like changes in the API, I think you should refrain
yourself until 5.2.1 is out.

> Ah, you use a tmp file just to reuse Geoff's code. But there is no reason to 
> not change that also latter, right?

You got it.  I have not against improving the code and putting all the
information in a structure, that can also be cached in the <driver>.rc
files.  The important point here is that we should not have a unique file
(like drivers.db) that contains the information about all available drivers.

> > 1) Portability.  I am using new libc functions (POSIX tmpfile, opendir,
> >    readdir and closedir).  Although am I following the recommended
> > procedure found in the Autoconf docs (i.e. using AC_HEADER_DIRENT and a
> > couple of tests with HAVE_DIRENT_H), I am sure that there will be some
> > weird system out there (MacIntosh, say) for which my code won't compile. 
> > If that happens, we have to port that part of the code.
> 
> Don't create the file :)

>From the smile, I guess you are joking.  I did not get the joke, though...

> >    c) At build time (not configuration time), a small C program dlopen the
> >       <driver>.c files,
> 
> You mean "open" and not dlopen(), right?

No, I meant dlopen (lt_dlopenext, to be more precise).

> No, you mean dlopen() the <driver>.so (I don't know the current suffix)

Yes, I mistakenly wrote <driver>.c.

> I prefer the full dynamic one, i.e., reading the already build drivers. I 
> don't think that performance will suffer.

It is not only a matter of time performance, but I was wondering about hte
fact that when all the module are dynamically loaded, all the libraries
(tcl, gd, gnome, etc.) will be unnecessarily dynamically linked.  I am just
specutlating about this, though.

> Do you have some figures or only feelings?

I have no figures, but my feeling is that it does not affect performance at
all.  I have here:

    $ cat /proc/cpuinfo | egrep "^(model n|cpu M|bogo)"
    model name      : Pentium III (Coppermine)
    cpu MHz         : 929.842
    bogomips        : 1854.66


> Your second idea implies that the small program that scans the source files
> [..]

No, it would "scan" the <driver>.la files (see above).

> [...] needs information from the configure step to know what drivers are
> desired by the user and supported by the system. This complicates matters.

Yes, the list of dynamic drivers is built at configure time and stored in
the variable DYNAMIC_DRIVERS, which is passed to drivers/Makefile.am.  
However, there will no further complication in the build process.  The
following addition to drivers/Makefile.am should do the job:

    drivers_DATA = $(drivers_LTLIBRARIES:.la=.rc)
    %.rc: %.la get_drv_info
            @echo get_drv_info $< $@

Where the get_drv_info.c is the C program that I mentioned already.	    
	
> With the first idea, by contrary, only already build drivers, i.e, user
> desired and system supported, are scanned.

If there is no drawback with this solution, I will adopt it (it is in CVS
already).  However, I would prefer a "info cached" approach.

> Also, with the second idea I think that the driver-ids (the magic numbers)
> can go away -- ah, no, for historical reasons the xwin driver must be
> number one, the tk driver number 2, etc. hmm, there is another solution for
> this but let discuss it latter.

Please, notice that these magic number (seqnum) are not so "magic".  They
only give a hint about how to order them.  Think on them like "priority
level". BTW, the gnome driver also has seqnum = 1.

> If performance is really an issue, then one could implements a mixing of
> the two ideas: don't generate drivers.db at configure nor build time. At
> run time if drivers.db does not exists, scan the drivers and build it. This
> way the performance loss will only occurs once. If a new driver is latter
> added to the directory (not probable, but possible, after all this is the
> only advantage of dyndrivers), one could first compare the time-stamp of
> all drivers versus the drivers.db file, and rebuild drivers.db if a driver
> is more recent. Reading time-stamp is fast, I believe.

This is a nice possibility, it is maybe the best solution, but someone has
to implement it.  It adds complexity to the code.  Volunteers? ;-)

-- 
Rafael

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* Maurice LeBrun <mj...@ga...> [2003-02-05 02:21]:

> I say move it.  It's been a while since any significant changes have been made
> to it IIRC, but soon I have plans for it.  And, one can always see the rev
> history by going to the drivers dir and doing a 'cvs log' even if the file
> has been cvs rm'ed.  Be sure to mention where it came from & what version
> in the first commit of the file in the new location.

Alan, could you take care of this?
 
-- 
Rafael

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

Rafael Laboissiere writes:
 > Why are we waiting to do the move?  The only drawback that I see is that we
 > will loose the commit history if we move the file, since braindead CVS does
 > not know how to move files in the repository tree.

I say move it.  It's been a while since any significant changes have been made
to it IIRC, but soon I have plans for it.  And, one can always see the rev
history by going to the drivers dir and doing a 'cvs log' even if the file
has been cvs rm'ed.  Be sure to mention where it came from & what version
in the first commit of the file in the new location.

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

Re: [Plplot-devel] New way of getting device info from dyndrivers

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

* Alan W. Irwin <ir...@be...> [2003-02-04 15:11]:

> Are you using "dlopen" in the generic sense here?  The actual call should
> be to lt_dlopenext, and you have to be careful of the argument (follow
> exactly what I did with drvnam and drvspec so the file name comes out
> exactly the same to get it to work cross-platform).

Of course, I used the libltdl interface (lt_dl* functions).  In particular,
the modules are open with lt_dlopenext.

> IIRC next.c is completely unmaintained and kept in CVS only as an
> encouragment for somebody, someday, to get it going again.

Okay.  This is something that will be absent of the 5.2.1 tarball, thnaks to
"make dist".

> plbuf.c is not a   driver  in the traditional sense.  I believe it is in the
> wrong directory and should be put in src instead.  It's code is put
> directly into the libplplot library (see src/Makefile.am).

Why are we waiting to do the move?  The only drawback that I see is that we
will loose the commit history if we move the file, since braindead CVS does
not know how to move files in the repository tree.

-- 
Rafael