Alan, Since these strings that are kept in files, that need to be associated with each possible driver, do not change over the years, why maintain a separate location? Why not just compile those strings into the body of plplot.obj? The increase of data size will probably be balanced by the decrease in support code.
On Mon, Apr 20, 2015 at 7:12 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2015-04-20 13:27-0700 Alan W. Irwin wrote: > >> On 2015-04-20 12:55-0700 Alan W. Irwin wrote: >> >>> Furthermore -debug works fine for me on MinGW/MSYS/Wine, but the only >>> extra output from it comes after the device is selected from the list >>> above. So to debug further you will have to (locally) add informative >>> pldebug calls to the code near where the error message above >>> "plInitDispatchTable: Could not open drivers directory, aborting >>> operation" is being generated. >>> >>> I look forward to seeing those results from you. >> >> Hi Arjen: >> >> Actually, I take that "works fine for me" back. If you look at the >> code, the error message is generated after a call to plGetDrvDir >> which has pldebug() calls in it. Those work on Linux. >> >> Here is what happens on Linux when the the ps device has not been built >> (to cut down on the debug output). >> >> software@raven> examples/c/x00c -debug -dev psc -o test.psc >> plLoadDriver: Device not loaded! >> plLoadDriver: tag=psc, drvidx=0 >> plGetDrvDir: Using /home/software/plplot/HEAD/build_dir/drivers as the >> driver directory. >> plLoadDriver: Trying to load ps on >> /home/software/plplot/HEAD/build_dir/drivers/ps >> plLoadDriver: lt_dlopenext failed because of the following reason: >> file not found >> Unable to load driver: ps. >> >> *** PLPLOT ERROR, IMMEDIATE EXIT *** >> Unable to load driver >> Program aborted >> >> So there is a message from plGetDrvDir above on exactly what drivers >> directory is being used in the build tree (which gets the build-tree >> version of that directory because of the plInBuildTree() result). >> >> On MinGW/MSYS/Wine here is the equivalent result (again without the >> ps.dll device available to make output short). >> >> bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc >> plLoadDriver: Device not loaded! >> plLoadDriver: tag=psc, drvidx=0 >> plLoadDriver: Trying to load ps on ps >> plLoadDriver: lt_dlopenext failed because of the following reason: >> No error information >> Unable to load driver: ps. >> >> *** PLPLOT ERROR, IMMEDIATE EXIT *** >> Unable to load driver >> Program aborted >> >> So in my particular MinGW/MSYS/Wine case I get this very strange >> result that either (1) there is no call to plGetDrvDir at all or (2) >> somehow pldebug is not working for just that particular routine. >> >> So I now find myself in the position of having to debug the -debug >> option on this platform, and I hope you try that as well. >> >> And if you figure out that last sentence, it means you are truly a PLplot >> guru. :-) > > Hi Arjen: > > To follow up, the above difference is actually expected because > plGetDrvDir is not called in that context on Windows platforms. > > However, that function is also called (both on Linux and Windows) in a > different context (from plInitDispatchTable) where -debug was silent > for all platforms. I have now corrected that silence (commit id > c44f636). > > Here is the new -debug result on MinGW/MSYS/Wine (still without > ps.dll built to shorten the messages). > > bash.exe-3.1$ examples/c/x00c -debug -dev psc -o test.psc 2>&1 |less > plGetDrvDir: Using > Z:/home/wine/newstart/build_script/build_dir-1.6.1/epa_build/Source/comprehensive_test_disposeable/shared/build_tree/drivers > as the driver directory. > plInitDispatchTable: Scanning dyndrivers dir > plInitDispatchTable: Consider file . > plInitDispatchTable: Consider file .. > plInitDispatchTable: Consider file ps.driver_info > plInitDispatchTable: Opened driver info file ps.driver_info > plInitDispatchTable: Consider file xfig.driver_info > plInitDispatchTable: Opened driver info file xfig.driver_info > plInitDispatchTable: Consider file pdf.driver_info > plInitDispatchTable: Opened driver info file pdf.driver_info > plInitDispatchTable: Consider file Makefile > plInitDispatchTable: Consider file null.driver_info > plInitDispatchTable: Opened driver info file null.driver_info > plInitDispatchTable: Consider file CMakeFiles > plInitDispatchTable: Consider file mem.driver_info > plInitDispatchTable: Opened driver info file mem.driver_info > plInitDispatchTable: Consider file svg.driver_info > plInitDispatchTable: Opened driver info file svg.driver_info > plInitDispatchTable: Consider file wingcc.driver_info > plInitDispatchTable: Opened driver info file wingcc.driver_info > plInitDispatchTable: Consider file ntk.driver_info > plInitDispatchTable: Opened driver info file ntk.driver_info > plInitDispatchTable: Consider file cmake_install.cmake > plInitDispatchTable: Consider file CTestTestfile.cmake > plLoadDriver: Device not loaded! > plLoadDriver: tag=psc, drvidx=0 > plLoadDriver: Trying to load ps on ps > plLoadDriver: lt_dlopenext failed because of the following reason: > No error information > Unable to load driver: ps. > > *** PLPLOT ERROR, IMMEDIATE EXIT *** > Unable to load driver > Program aborted > > So obviously in this case the drivers directory is being found properly > by plGetDrvDir called from plInitDispatchTable. > > If you look at the plGetDrvDir code in src/plcore.c, the only > case where PLPLOT_DRV_DIR is important is if the build-tree > detection fails. > > So basically the difference between us is > > plInBuildTree() == 1 > > for my platform but not for yours which you can confirm by > doing the above individual test and looking at > the form of the first message that comes out (which is > different if plInBuildTree() == 1 is not detected). > > And if the build-tree detection is failing for you that screws up lots > of other build-tree stuff, and jibes with you having to brute-force > the problem by setting other PLPLOT-related environment variables as > well. > > It turns out the plInBuildTree logic depends closely on whether the > directory separator is a "/" or a "\", and I suspect what has happened > is my older version of MSYS uses "\" while your more modern version > uses "/" in this context. > > Accordingly, I have changed the plInBuildTree code to work for either > separator on Windows (commit ID 8ffab0b). That change gave the same > good results as above for me, and I hope it will also solve _all_ your > brute force issues (i.e., reliance on PLPLOT* environment variables > can be dropped) on your more modern MinGW/MSYS. > > If that change works for you with individual tests, then please follow > up with the corresponding comprehensive test with no PLPLOT-* > environment variables set. And if that is a success please > repeat with > > --do_clean_as_you_go no > > dropped (since there is no need to chew up your disk space anymore) > > and you also should drop > > --do_ctest no > --do_test_interactive no > > to make the test as strong as possible (outside using the epa_build > variation of this test which strengthens it even more by building some > of the soft dependencies for PLplot such as pkg-config, Tcl/Tk, qhull, > and shapelib). > > If you have any failures along the way, the usual corresponding > tarball is requested. But if every test is a success, then you are > done with MinGW/MSYS testing (YEAH!), and I only need that tarball for the > last (strongest) test so I can post those good results on our wiki as > a benchmark to help guard against future regressions introduced in > this release cycle. > > I hope you find these new developments as interesting as I do. I have > been frustrated for years by PLplot just not working very well on the > various Windows platforms, and it feels really good to be able to > tackle some of these issues now thanks to your willingness to run > comprehensive tests on various Windows platform and the vastly > improved automatic data collection for your comprehensive test results > that now exists. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
