Menu
▾
▴
plplot-devel
|
From: Maurice L. <mj...@ga...> - 2003-02-10 03:14:49
|
Alan W. Irwin writes: > Summary: the new code loops over every device so will trigger the > complete collection of valgrind errors for all devices (just xwin in this > case) while the old code just looked at the user-specified device so gets no > valgrind errors (except when the user specified xwin). I've not been following the discussion very closely, but does this mean that the code currently loads all dynamic drivers at startup time? If true, this seems against the spirit of dynamic drivers, and adds unnecessarily to the memory used by the application. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Alan W. I. <ir...@be...> - 2003-02-10 05:26:34
|
On Sun, 9 Feb 2003, Maurice LeBrun wrote: > Alan W. Irwin writes: > > Summary: the new code loops over every device so will trigger the > > complete collection of valgrind errors for all devices (just xwin in this > > case) while the old code just looked at the user-specified device so gets no > > valgrind errors (except when the user specified xwin). > > I've not been following the discussion very closely, but does this mean that > the code currently loads all dynamic drivers at startup time? If true, this > seems against the spirit of dynamic drivers, and adds unnecessarily to the > memory used by the application. Good question..... Here is my understanding of our current situation. Rafael's code is designed on startup to momentarily load each driver to collect and store required information about it (as opposed to storing the required information in drivers/drivers.db). And Joao did some timing to show this loading of all drivers was very fast. However, at the moment "momentarily" is until exit from PLplot and consequently PLplot uses more memory then it should because of a bug in libltdl that doesn't allow unloading. But once that bug is fixed it is only a matter of uncommenting one line in plcore.c to get a leaner, meaner PLplot. 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 __________________________ |
|
From: <jc...@fe...> - 2003-02-10 11:30:04
|
Quoting "Alan W. Irwin" <ir...@be...>: > On Fri, 7 Feb 2003, Rafael Laboissiere wrote: > > > * Alan W. Irwin <ir...@be...> [2003-02-06 18:52]: > > > > > The most important point, however, is you do see segfaults on your > machine > > > so you have confirmed there is a severe problem, and you therefore have > > > something that you can debug for your situation. > > > > > > Good luck in figuring this out! > > > > I think I found the source of the problem, see my last cvs commit. Could > > you guys confirm that HEAD works for you now? > > Yes with a qualification. > > No segfaults for ./x01c with the "Joao" configuration. Try removing the tkwin driver from the install directory and uncommenting the lt_dlclose (dlhand) in plcore.c that Rafael last cvs commit has commented. x01c now works for me. tkwin is a bad-boy! Joao PS-there is no need to remove the tkwin.* files, it's enough to > mv tkwin.la tkwin.la- To get the tkwin (not) working again is enough to > mv tkwin.la- tkwin.la as Rafael code only tries to load files that have a .la extension. That's the beauty of the scheme! (that should only be a bitmore robust.) |
|
From: Rafael L. <lab...@ps...> - 2003-02-10 15:53:19
|
* jc...@fe... <jc...@fe...> [2003-02-08 03:45]: > Try removing the tkwin driver from the install directory and uncommenting the > lt_dlclose (dlhand) in plcore.c that Rafael last cvs commit has commented. > x01c now works for me. tkwin is a bad-boy! I can replicate this bug here. The tkwin driver has probably some memory management problems that make surface when lt_dlopenext/lt_dlclose are used. That's weird, eh? -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2003-02-10 18:27:00
|
On Mon, 10 Feb 2003, Rafael Laboissiere wrote: > * jc...@fe... <jc...@fe...> [2003-02-08 03:45]: > > > Try removing the tkwin driver from the install directory and uncommenting the > > lt_dlclose (dlhand) in plcore.c that Rafael last cvs commit has commented. > > x01c now works for me. tkwin is a bad-boy! > > I can replicate this bug here. The tkwin driver has probably some memory > management problems that make surface when lt_dlopenext/lt_dlclose are used. > That's weird, eh? I don't completely trust such interpretation because I have seen segfaults come and go depending on the placement (!) of print statements in the code. It is very hard to track down the real reason for segfaults until you use a tool like valgrind. valgrind does indicate a problem with xwin even when lt_dlclose is commented out. So I suggest the best test is to uncomment lt_dlclose and exclude both xwin and tkwin. Under those circumstances, then I would believe the above interpretation (problem somewhere in either xwin or tkwin or both) if the valgrind result is clean. Otherwise not. I don't have time to run this specific test now, but I will do so in the next few days if nobody else is curious enough to try it. 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 __________________________ |
|
From: Rafael L. <lab...@ps...> - 2003-02-11 06:36:58
|
* Alan W. Irwin <ir...@be...> [2003-02-10 10:25]: > I don't completely trust such interpretation because I have seen segfaults > come and go depending on the placement (!) of print statements in the code. > It is very hard to track down the real reason for segfaults until you use a > tool like valgrind. > > valgrind does indicate a problem with xwin even when lt_dlclose is > commented out. So I suggest the best test is to uncomment lt_dlclose and > exclude both xwin and tkwin. Under those circumstances, then I would > believe the above interpretation (problem somewhere in either xwin or tkwin > or both) if the valgrind result is clean. Otherwise not. I understand your point and I agree that such bugs are hard to be tracked down. However, the simple fact that dlopening/dlclosing tkwin.la _with everything else kept equal_ makes it a quite good candidate for culprit. Indeed, there are tones of malloc, calloc, ckcalloc, etc calls in the source files (drivers/tk*.c and bindings/tk/*.c). I cannot tell if they are suspicious or not, though. That said, it is possible that the code in xwin.c is equally bad... At any rate: > I don't have time to run this specific test now, but I will do so in the > next few days if nobody else is curious enough to try it. we are looking forward for the results of your valgrind tests. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2003-02-12 07:32:32
|
On Mon, 10 Feb 2003, Alan W. Irwin wrote: > On Mon, 10 Feb 2003, Rafael Laboissiere wrote: > > > I can replicate this bug here. The tkwin driver has probably some memory > > management problems that make surface when lt_dlopenext/lt_dlclose are used. > > That's weird, eh? > > I don't completely trust such interpretation.... I ran the valgrind test I suggested with lt_dclose uncommented and excluding certain drivers. This test was based on the 10 February software. The point of this test is to look for memory management problems in the current set of drivers with this old code rather than to look at the code Rafael just checked in which (I believe) avoids making this test of lt_dlopenext/lt_dlclose for every driver. I found I got an absolutely clean valgrind result (except for well known unfreed memory warnings at programme end) if I excluded xwin, tkwin, tk, and gd. Here was the list of drivers for the clean result: ls ../../driversd/*.so ../../driversd/cgm.so* ../../driversd/ljiip.so* ../../driversd/pstex.so* ../../driversd/dg300.so* ../../driversd/null.so* ../../driversd/tek.so* ../../driversd/hpgl.so* ../../driversd/pbm.so* ../../driversd/xfig.so* ../../driversd/impress.so* ../../driversd/plmeta.so* ../../driversd/ljii.so* ../../driversd/ps.so* ldd shows that each of these is dynamically linked just to libplotd, libm, libc, and libdl. (cgm is also linked to the cd library, but that is a static library so its a different case than gd, xwin, tkwin, and tk which all are linked to extra dynamic libraries.) If I added in gd, then I got valgrind errors, but no segfault. In a previous test with gd, xwin, and tkwin (and tk?) we got segfaults. There does seem to be a pattern developing that all drivers linked to extra dynamic libraries have memory management problems of some kind that are reported by valgrind. I cannot draw a definitive conclusion from this, but there is certainly the possibility that a libtool (libltdl) bug could be the cause of this pattern, and I will certainly check gd, xwin, tkwin, and tk again once a new version of libtool is released. For now, though, it is best to avoid lt_dlclose (which I think the latest code from Rafael does). In this case (commented out lt_dlclose) we do get valgrind errors, but so far (knock on wood for luck!) no segfaults have showed up. I am completely sold on autotools as a convenient way to set up the configuration of our software. However, I am sure looking forward to the day that autotools stabilizes! 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 __________________________ |
|
From: Rafael L. <lab...@ps...> - 2003-02-12 12:54:30
|
Thanks for your report on the test results. Only a confirmation: * Alan W. Irwin <ir...@be...> [2003-02-11 23:31]: > [...] For now, though, it is best to avoid lt_dlclose (which I think the > latest code from Rafael does). Yes, it does. -- Rafael |
|
From: <jc...@fe...> - 2003-02-10 15:17:44
Attachments:
po.c
|
On Monday 10 February 2003 07:13, Rafael Laboissiere wrote:
| * Maurice LeBrun <mj...@ga...> [2003-02-09 21:13]:
| > I've not been following the discussion very closely, but does this
| > mean that the code currently loads all dynamic drivers at startup
| > time? If true, this seems against the spirit of dynamic drivers,
| > and adds unnecessarily to the memory used by the application.
|
| This is what I thought at the beginning and this is why I proposed
| the alternative design with the <driver>.rc files. However here is
| what Joao wrote some days ago:
|
| * Jo=E3o Cardoso <jc...@fe...> [2003-02-07 14:51]:
| > Your concerns that dlopen() would load all libraries that a driver
| > needs does not apply, as this would only happens if some drivers
| > code is executed, which is not the case. As libtool's info says:
| >
| > "Unresolved symbols in the module are resolved using
| > its dependency libraries"
| >
| > As the symbols you are looking for are in the modules, no further
| > loading will occur.
Further, the libtool docs says that RTLD_LAZY is used when dlopen() is=20
effectively called.
But one thing is what the docs says, the other what is done.
What valgrind reports (in the attached program) is that libs are loaded:=20
=2E..
=3D=3D20614=3D=3D discard syms in /usr/lib/libjpeg.so.62.0.0 due to munma=
p()
=2E..
This seems to indicate that libjpeg was loaded, and latter unloaded,=20
even if not used, i.e., no code from it was executed and no symbol=20
belonging to it requested.
But the dlopen() man page also says:
If the library exports a routine named _init, then that
code is executed before dlopen returns.
and:
[jcard@feup] nm -p /usr/lib/libjpeg.so | fgrep _init
0001aaa0 T jpeg_mem_init
00001fd4 T _init
a _init function is defined in the library, meaning that it must be=20
executed. This must also happens for other libraries, as valgrind gives=20
the same kind of warning for other libraries.
Of course on most systems the libraries are not loaded, as they are=20
already loaded by the several programs the user is working with, but=20
there are of course exceptions.
Back to the drivers.rc solution, Rafael.
The attached program also shows that the bug we found does not seems to=20
be in the libtool library, but in the system's libdl, as the program=20
calls dl*() directly.
Joao
|
| I hope that this is true for all architectures.
|
| At any rate, as Alan pointed out, in the current design the driver
| moudles should be dlclosed after the plD_DEVICE_INFO_<dirver>
| variable is obtained.
|
|
From: Rafael L. <lab...@ps...> - 2003-02-10 15:55:09
|
Thanks for your useful report on library loading, Joao. * João Cardoso <jc...@fe...> [2003-02-10 15:19]: > Back to the drivers.rc solution, Rafael. I will give it a try one of these days. -- Rafael |
|
From: <jc...@fe...> - 2003-02-10 18:06:46
|
On Monday 10 February 2003 15:44, Rafael Laboissiere wrote: | Thanks for your useful report on library loading, Joao. | | * Jo=E3o Cardoso <jc...@fe...> [2003-02-10 15:19]: | > Back to the drivers.rc solution, Rafael. | | I will give it a try one of these days. If dlopen() is called with RTLD_NOW instead of RTLD_LAZY in the program=20 that I attached in my last e-mail, it work's OK (and its output is=20 similar to drivers.db). But libtool docs says that RTLD_LAZY is used by default, so we might=20 have a problem. However, a comment in libtool-1.4.3/libltdl/ltdl.c=20 seems to indicate that this is an issue in some platforms: /* We may have to define LT_LAZY_OR_NOW in the command line if we find out it does not work in some platform. */ With the small program is also easier to check for memory leaks with=20 valgrind, and most of the leaks come from libdl. tmpfile() also contributes a bit. Joao PS-Also usefull are some environmental variables used by ld.so: > man ld.so=20 > LD_DEBUG=3Dhelp ./po |
|
From: Rafael L. <lab...@ps...> - 2003-02-06 23:02:21
|
* Alan W. Irwin <ir...@be...> [2003-02-06 10:09]: > I think you need quotes around the -I option to bootstrap.sh as above > (contrary to your commit message). Otherwise, the $1 in bootstrap.sh will > just catch the -I and miss the rest. That's fixed, see cvs commit log. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2003-02-04 23:12:34
|
On Tue, 4 Feb 2003, Rafael Laboissiere wrote: > 3) When the library is initialized, if dyndrivers are enabled, the drivers > directory is scanned for the *.la files. Each found driver is dlopened > and the DEVICE_INFO_<driver> symbol is read and put in a temporary file. 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). > c) At build time (not configuration time), a small C program dlopen the > <driver>.c files, Same comment. My initial use of lt_dlopenext worked fine on Linux but died horribly on OSF1 until I made my final changes to the lt_dlopenext argument. > Postscript > ========== > > In doing my changes, I noticed that the following drivers have never had > entries in drivers.db: plbuf.c and next.c. Does anyone know why? IIRC next.c is completely unmaintained and kept in CVS only as an encouragment for somebody, someday, to get it going again. 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). > I also noticed that the > pstex entry was wrongly written in drivers.db. Apparently, this bug have > never bothered our users... I have forgotten the details, but IIRC, I checked that drivers.db anomaly before, and I am pretty sure it is necessary in order for pstex to work. Something to do with the way pstex depends on ps or vice versa. Joao, do you remember about this? 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 __________________________ |
|
From: Joao C. <jc...@fe...> - 2003-02-05 02:11:23
|
On Tuesday 04 February 2003 23:11, Alan W. Irwin wrote: > On Tue, 4 Feb 2003, Rafael Laboissiere wrote: =2E.. > > I also noticed that the > > pstex entry was wrongly written in drivers.db. Apparently, this bug = have > > never bothered our users... > > I have forgotten the details, but IIRC, I checked that drivers.db anoma= ly > before, and I am pretty sure it is necessary in order for pstex to work= =2E > Something to do with the way pstex depends on ps or vice versa. > > Joao, do you remember about this? No. I only remember that the pstex configuration changed a couple of time= s. The pstex needs the ps driver, directly calling the ps driver entry point= s. If it works with Rafael changes, that's fine for me. For a quick test use= any=20 C example and the scripts/pstex2eps script to generate an eps. > > Alan |
|
From: Rafael L. <lab...@ps...> - 2003-02-05 11:25:44
|
* 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 |
|
From: Rafael L. <lab...@ps...> - 2003-02-05 08:16:59
|
* 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 |
|
From: Maurice L. <mj...@ga...> - 2003-02-05 08:22:56
|
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) |
|
From: Rafael L. <lab...@ps...> - 2003-02-05 09:27:40
|
* 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 |
|
From: Alan W. I. <ir...@be...> - 2003-02-05 14:44:59
|
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 __________________________ |
|
From: Joao C. <jc...@fe...> - 2003-02-05 02:56:48
|
On Tuesday 04 February 2003 21:37, Rafael Laboissiere wrote:
> Preamble
> =3D=3D=3D=3D=3D=3D=3D=3D
>
> The big recent cvs commit regarding the dyndrivers database was on the =
top
> of my TODO list. It is a necessary step towards clean
> configuration/building and also packaging for Debian.
>
> I am not yet completely happy with my implementation, but my changes
> (apparently) did not break PLplot. My simple test script succeeded, at
> least. I am committing without previous discussion here because, as Al=
an
> uses to say, getting novelties in cvs HEAD is the best way to foster
> discussions.
That's true, but the target should be to get a full-working 5.2.1, that s=
hould=20
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.
I have myself lots of new stuff, and I'm refraining myself to commit them=
=2E I=20
hope that 5.2.2 or even 5.3.0 follows shortly.
>
> The Problem
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The way PLplot used to get information about the available devices prov=
ided
> by the dyndrivers was through the DATA_DIR/drivers.db file. This file =
was
> generated at configuration time and parsed when the library was
> initialized.
>
> This approach has two drawbacks:
>
> 1) Information about the devices are scattered in different places (nam=
ely
> in the driver source file and in configure.ac). This is ugly and ma=
y
> result in unnecessary maintenance burden.
>
> 2) Since the list of available devices is hardcoded in the drivers.db i=
t is
> almost impossible to do clean packaging of Plplot. In Debian, for
> instance, packaging is granular in order to reduce the dependencies:
> plplot-xwin, plplot-tk, plplot-gd, etc. Users can install a subset =
of
> the available packages at will. However, they will always get the f=
ull
> list of available devices when plinit is called. That is not a crit=
ical
> problem, but annoying.
>
>
> The Solution
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> I have elaborated a full fix for this problem, but I just committed an
> intermediary solution for it. Here is how it works:
>
> 1) drivers.db does not exist anymore.
>
> 2) In each driver file, there is a global declaration like this:
>
> char* DEVICE_INFO_gd =3D "jpeg:JPEG file:0:gd:40:jpeg\n"
> "png:PNG file:0:gd:39:png";
OK, but we need a registration text file, manually maintained, to guide n=
ew=20
drivers writers on how to obtain (and register) new ids for the new drive=
rs.=20
>
> containing the entries that used to go into drivers.db. If a driver
> provides more than one device, their entries must be separated by a
> newline character ('\n').
>
> 3) When the library is initialized, if dyndrivers are enabled, the driv=
ers
> directory is scanned for the *.la files. Each found driver is dlope=
ned
> and the DEVICE_INFO_<driver> symbol is read and put in a temporary f=
ile.
>
> 4) This temporary file plays the role of the old drivers.db file.
Why is the tmp file needed? Why not keep the collected info in an interna=
l=20
structure?
> Noticed that I did minimal changes to Geoff's code in plcore.c. In the
> plInitDispatchTable function, I replaced the initial code (where the
> drivers.db were scanned) by the scanning of the drivers directory descr=
ibed
> in point 3 above.
Ah, you use a tmp file just to reuse Geoff's code. But there is no reason=
to=20
not change that also latter, right?
> Also, all references to drivers.db and DRIVERS_DB have disappeared from=
the
> sources.
>
>
> Drawbacks and improvements
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>
> I see two potential problems with my approach:
>
> 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=
=2E=20
> If that happens, we have to port that part of the code.
Don't create the file :)
> 2) With my approach, I have to open all and every module before using t=
hem.
> This may appear as a regression as regards the "cache file" approach
> provided by the use of drivers.db. In terms of performance, with ou=
r
> current computer power, the overload is negligible. However, as I w=
rote
> above, my original design was much better, but harder to implement (=
of
> course). It looks like this:
>
> a) Forget about that entries a la drivers.db.
>
> b) In each driver file <driver>.c define symbols DEV_DESC_*, DEV_SEQ=
_*,
> DEV_TAG_*, etc. These symbols can be used when filling fields in
> function plD_dispatch_init_<device>. This would further reduce t=
he
> maintenance problem due to duplication of information.
>
> c) At build time (not configuration time), a small C program dlopen =
the
> <driver>.c files,
You mean "open" and not dlopen(), right?
> get the symbols
No, you mean dlopen() the <driver>.so (I don't know the current suffix)
What do you really mean? Anyway, see bellow.
> described above and write the
> associated device entries in <driver>.rc (or whichever name).
>
> d) Those <driver>.rc are installed in the drivers directory, along w=
ith
> the <driver>.la and <driver>.so files.
>
> e) When PLplot is initialized, the <driver>.rc files are scanned.
>
> If I have some time before the 5.2.1 release, I will try to implemen=
t
> this idea.
I prefer the full dynamic one, i.e., reading the already build drivers. I=
=20
don't think that performance will suffer. Do you have some figures or onl=
y =20
feelings?
Your second idea implies that the small program that scans the source fil=
es=20
needs information from the configure step to know what drivers are desire=
d by=20
the user and supported by the system. This complicates matters.
With the first idea, by contrary, only already build drivers, i.e, user=20
desired and system supported, are scanned.
Also, with the second idea I think that the driver-ids (the magic numbers=
) can=20
go away -- ah, no, for historical reasons the xwin driver must be number =
one,=20
the tk driver number 2, etc. hmm, there is another solution for this but =
let=20
discuss it latter.
If performance is really an issue, then one could implements a mixing of =
the=20
two ideas: don't generate drivers.db at configure nor build time. At run =
time=20
if drivers.db does not exists, scan the drivers and build it. This way th=
e=20
performance loss will only occurs once.
If a new driver is latter added to the directory (not probable, but possi=
ble,=20
after all this is the only advantage of dyndrivers), one could first comp=
are=20
the time-stamp of all drivers versus the drivers.db file, and rebuild=20
drivers.db if a driver is more recent. Reading time-stamp is fast, I beli=
eve.
Joao
|
|
From: Rafael L. <lab...@ps...> - 2003-02-05 09:28:52
|
* 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
|
|
From: Rafael L. <lab...@ps...> - 2003-02-05 14:05:46
|
* 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
|
|
From: <jc...@fe...> - 2003-02-05 16:56:30
|
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.
|
|
From: Rafael L. <lab...@ps...> - 2003-02-05 17:25:25
|
* 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 |
|
From: <jc...@fe...> - 2003-02-05 21:06:02
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X