[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