From: Rafael L. <lab...@ps...> - 2003-10-05 00:03:19
|
A new CVS snapshot distribution tarball for PLplot is available at the usual place: http://people.debian.org/~rafael/plplot.html You will find below the changelog of the recent changes in CVS. Please, test and report. -- Rafael ============== Changelog ============== 2003-10-05 01:42 rlaboiss * lib/csa/Makefile.am: Removed csa_internal.h from EXTRA_DIST. 2003-10-04 23:05 airwin * drivers/README.drivers: This is the long-promised update of this basic documentation file for writing device drivers for PLplot. 2003-10-04 22:29 jcard * lib/nn/Makefile.am, lib/nn/delaunay.c, lib/nn/delaunay.h, lib/nn/hash.c, lib/nn/hash.h, lib/nn/linear.c, lib/nn/lpi.c, lib/nn/nan.h, lib/nn/nn.h, lib/nn/nnai.c, lib/nn/nncommon.c, lib/nn/nnpi.c, lib/nn/version.h, src/plgridd.c: Update to nn version 1.38 2003-10-04 22:25 jcard * lib/csa/csa_internal.h: Not needed in csa version 0.22 2003-10-04 22:24 jcard * lib/csa/: csa.c, csa.h, nan.h, version.h: Update to csa version 0.22 2003-10-04 19:53 airwin * examples/: c/Makefile.examples.in, c++/Makefile.examples.in, f77/Makefile.examples.in, tk/Makefile.examples.in: Put in EXEEXT (executable extension) support for those platforms like Cygwin that require it. Also, make the clean and all targets identical. 2003-10-04 14:08 airwin * examples/c/Makefile.examples.in: rm ==> rm -f 2003-10-03 18:28 airwin * bindings/c++/plstream.cc: AWI for Andrew Ross <an...@co...>. Correct problem with too many lines commented out while removing the plinit() calls from the plstream constructor. This two-line change to the API does not affect the current examples, but according to Andrew does affect other programmes using the PLplot C++ API. 2003-10-02 08:47 airwin * Makefile.am: Bug fix for changed way we now handle libltdl. Only do libltdl directory for case when dyndrivers are enabled. 2003-10-01 23:05 airwin * bindings/java/README.javaAPI: Update documentation to reflect building of installed java examples that now occurs automatically and the new installed location for the module (DLL) for the java PLplot interface. 2003-10-01 22:52 airwin * bindings/java/Makefile.am: Complete reorganization following what is done for ../../bindings/python/Makefile.am. Note that install-exec-hook: is now used to compile all the installed java files rather than compiling them in a local directory underneath bindings/java before installation, and this reduces a lot of clutter that was occurring before. Another notable change is the java module that interfaces to PLplot is no longer built like a full-blown library with a version number, precision tag, etc. with installation into $prefix/lib with appropriate version number symlinks. Instead, it is built similarly to the python module and installed in the location where the core java and compiled class files are installed. 2003-10-01 22:41 airwin * bindings/java/: PLStreamc.java, config.java.in: For PLStreamc.java, change from System.loadLibrary( plplot.core.config.libname ); to System.load( plplot.core.config.libname ); The former requires setting LD_LIBRARY_PATH on Linux/Unix systems (ugh, that is old-fashioned!). The latter requires an absolute path name + exact name of dynamically loaded module which is setup in configure.ac and configured using config.java.in. Yipee! No more setting of LD_LIBRARY_PATH is required for PLplot java use! 2003-10-01 22:29 airwin * configure.ac: * Only do libltdl related actions if dyndrivers is enabled. * Define AC_SUBSTituted variables JAVA_INSTDIR and PLPLOTJAVAC_WRAP_DLL for the absolute path of the Java install location, and the name of the module for interfacing java to PLplot that is (now) installed in that location. 2003-10-01 22:22 airwin * acinclude.m4: Add another macro, GET_DLLNAME, for getting the name for dynamically loaded libraries (modules). This macro has largely been copied from GET_DLNAME. On many systems the name for modules is just simply namestem.so, but we cannot assume that for all Unix platforms. 2003-10-01 22:12 airwin * bindings/python/README.pythonbuild: Tweak wording to reflect Mac OS X success. 2003-10-01 22:10 airwin * bindings/python/Makefile.am: Drop -no-undefined from LDFLAGS for the creation of the module that will be dynamically loaded by python. It makes no sense to resolve every reference at link time since python will be supplying the references to the python library names at dynamic load time. (Thanks to Rob Managan for his Mac OS X error report on this issue.) 2003-10-01 22:03 airwin * examples/java/README.javademos: Update documentation reflecting the automatic build of the examples by make install. 2003-10-01 21:59 airwin * test/test_java.sh: Update commentary. 2003-10-01 21:54 airwin * examples/java/Makefile.am: Compile java examples after installation. This is contrary to what we do for our other compiled language examples, but seems consistent with what is normally done for distribution of java software. 2003-10-01 21:50 airwin * examples/c++/Makefile.am: $(LN_S) must be preceded by rm -f. (Thanks to Rob Managan for his error report concerning this issue.) 2003-10-01 21:38 airwin * doc/docbook/: docbook.m4, src/Makefile.am: As discussed on the list deal with SourceForge username consistently both for configure time using the --with-www-user=NAME option and at make time overriding the WWW_USER variable using make WWW_USER=NAME Previously, overriding the make variable required a trailing @ in the NAME, but now NAME is treated identically in both cases with no trailing @ required. 2003-10-01 12:58 rlaboiss * configure.ac, include/plConfig.h.in: Better wording in comment for PL_DOUBLE The comment preceeding #define PL_DOUBLE is now clearer. Thanks to Arjen Markus <arj...@wl...> for the suggestion. |
From: Rafael L. <lab...@ps...> - 2003-10-19 10:48:40
|
A new CVS snapshot distribution tarball for PLplot is available at the usual place: http://people.debian.org/~rafael/plplot.html The tarball name is plplot-5.2.1.cvs.20031019.tar.gz. It was generated in a Debian unstable system with the following versions of the GNU autotools: Autoconf 2.57 Automake 1.7.8 Libtool 1.5.0a You will find below the changelog of the recent changes in CVS (generated with the command: cvs2cl -l "-d'2003-10-06<'"). Please, test and report. -- Rafael ============== Changelog ============== 2003-10-17 15:16 rlaboiss * debian/changelog: Debian release 5.2.1-20 2003-10-17 14:16 rlaboiss * configure.ac: Put AC_CHECK_LIB(ltdl, ...) outside the with_ltdlsystem conditional For some mysterious reason, when the AC_CHECK_LIB was put inside the conditional 'if test "$with_ltdlsystem" = no', configure was failing with the error message: conditional "AMDEP" was never defined. This should be fixed now. Please, test this change. 2003-10-16 13:22 rlaboiss * debian/: changelog, control, rules: Preparation for Debian release 5.2.1-20 This will be uploaded to unstable only after version 5.2.1-19 had hit the testing distribution. From debian/changelog: * Following a suggestion of Matthias Klose <do...@cs...>, the libltdl library shipped with the upstream sources is not compiled anymore as a convenience library: - Imported configure.ac and Makefile.am from upstream CVS that implement the confgiure option --with-ltdlsystem, allowing the use of the installed libltdl library. - debian/control: Build-depends on libltdl3-dev. - debian/rules: Call configure with option --with-ltdlsystem. * debian/control: - Fixed description of libplplot-dev package. - Bumped the build-dependency on debhelper to version 4.1.67, since we are using dh_python (thanks again to Matthias Klose for pointing this out). 2003-10-16 13:13 rlaboiss * configure.ac: Cosmetic changes Removed an obsolete comment about AM_PROG_LIBTOOL and added AC_HELP_STRING in MY_ARG_WITH(pthreads, ...). 2003-10-16 12:43 rlaboiss * Makefile.am, configure.ac: Better logic for use of system's libltdl The decision about when to use the libltdl library is improved. Now, the default is to always compiled the shipped libtool's libltdl as a convenience library, unless the user explicitly give the option --with-ltdlsystem to configure. When this option is given, confgiure checks if the libltdl library is actually installed. If not, it falls back to the convenience compilation case. Alan, if you are hearing this, could you please comment? 2003-10-16 03:06 jcard * src/plcore.c: plInBuildTree() is always needed, move out of conditional ENABLE_DYNDRIVERS 2003-10-16 02:05 rlaboiss * Makefile.am, configure.ac: Allow use of installed libltdl A Debian fellow pointed out to me that there is no need to compile the libltdl support when building the PLplot Debian packages, since there is a libltdl3 package against which libplplot can be linked. In order to be able to disable configuration/compilation of the libltdl support, I did the following changes: * In configure.ac, AC_LIBTOOL_CONVENIENCE and AC_LIBTOOL_INSTALLABLE are called conditionally on the presence of an installed libltdl (using AC_CHECK_LIB). * In order to avoid config/build of the libltdl directory, AC_CONFIG_SUBDIRS(libltdl) is called conditionally as well. Also, in Makefile.am, the libltdl directory is included conditionally on the (newly created) AM_CONDITIONAL variable enable_ltdl_convenience. [N.B.: I changed the code for setting the SUBDIRS variable in Makefile.am using the automake append (+=) operator, instead of using the auxiliary variable drivers_src_dirs as before.] If the user has libltdl installed in the system but wants to use the version shipped with PLplot, she can override the configure check by giving the --enable-ltdl-convenience option (this needs further tests, though). The advantage of using the system's libltdl are: * Configuration time is reduced, since the libltdl dir does not need to be configured. * Build time is also reduced, for a similar reason. * The size of the resulting libplplot library is around 10% smaller (at least in Linux). 2003-10-15 23:36 rlaboiss * pkgcfg/Makefile.am: Fixed problem with sed option -i Option -i of the sed command is quite useful, because it allows files to be edited in-place. It is too bad that GNU sed older than version 4 do not support this feature. Since this should be the case for general sed's, the use of option -i was replaced by an ugly (but working) code using a temporary file. 2003-10-15 23:31 rlaboiss * pkgcfg/gen-pc-files.sh: Added some output messages In the for loop, messages like "Generated plplot(...).pc" are now echoed. This will help to diagnose problems in the future. Also, some small reformatting of the code was done. 2003-10-15 22:53 rlaboiss * pkgcfg/gen-pc-files.sh: Added missing double quote in sed command This fixes the 'command substitution: unexpected EOF while looking for matching "' bug. Quite interesting, this error message is only triggered when /bin/sh is bash. Other Bourne shells like ash and dash accept happily this "syntax error". 2003-10-11 19:48 rlaboiss * pkgcfg/: Makefile.am, README: Fixed parsing of -L... entries in dependency_libs The -L... entries were incorrectly parsed in the install-data-hook rule and disappeared from the Libs lines in the *.pc files. The documentation README is updated to reflect this fix. 2003-10-11 15:40 rlaboiss * configure.ac, pkgcfg/Makefile.am, pkgcfg/README, pkgcfg/gen-pc-files.sh, pkgcfg/plplot-float.pc.in, pkgcfg/plplot-master-pc.in, pkgcfg/plplot.pc.in: Total redesign of the pkg-config support for PLplot Read the pkgcfg/README file for details. 2003-10-11 10:20 rlaboiss * pkgcfg/: Makefile.am, plplot-float.pc.in, plplot.pc.in: pkg-config gives now complete list of dependency libraries This is a first try to have "pkg-config plplot --libs" working correctly in a cross-platform way. For that, the complete list of dependency libraries flags (-l*) must be included into plplot.pc and plplot-float.pc. This information is already available in the src/.libs/libplplot*.lai files. These files are parsed in the install-data-hook rule of pkgcfg/Makefile.am in a similar way the plplot_libtool script does at run time. However, this is done at install time. This is now the result I am having in Linux (must be also tested in other platform): $ pkg-config plplot --libs -lplplotd -lfreetype -lz -lcsirocsa -lcsironn -lqhull -lm -ldl 2003-10-10 20:57 airwin * scripts/plplot-config.in: Update and partial redesign of plplot-config, a simplified wrapper for plplot_libtool if you don't want to use the power of that script directly. * fixed bugs where it failed for libtool-1.5 (a linker must be specified), and also failed for --with-c++ (wrongly named library). * introduce --with-f77 and --with-tcl options * non-cumulative library modes. The idea here is you ordinarily only tell plplot_libtool about libplplot, and it figures out the correct link options for the local platform based on that. However, there are some additional mutually exclusive options a user can specify: --with-c++, --with-f77, or --with-tcl. If you specify any of those additional switches you tell plplot_libtool only about the appropriate library (libplplotcxx for --with-c++, libplplotf77 for --with-f77, and libplplottcltk for --with-tcl), and it determines the correct link options for your local platform. The above switches should be mutually exclusive, but my scripting skills aren't up to checking for that (help, please!), but for now I settled for an increasing order of precedence being in the above order (so anything lower on the list means anything above is ignored). 2003-10-10 20:26 jcard * examples/: tcl/README.tcldemos, tk/README.tkdemos: Adjust to show how to run the demos in the build tree. 2003-10-10 20:26 jcard * bindings/: tcl/pkgIndex.tcl.in, tk/pkgIndex.tcl.in, tk-x-plat/pkgIndex.tcl.in: Fix to enable the demos to be run in the build tree. 2003-10-10 15:17 rlaboiss * pkgcfg/: plplot-float.pc.in, plplot.pc.in: Fixed Libs and Cflags entries Added "/plplot" to the includedir variable, such that there is no need to explicitly #include <plplot/...> in user programs (this is the case for the C and C++ examples shiped with PLplot). Also, removed -DPL_DOUBLE from Cflags (this was producing compilation warnings, since PL_DOUBLE is already defined in plConfig.h) and removed @FREETYPELIBCMD@ from Libs. All the dependecy libraries of libplplot are guessed by the default linker of Linux. I am not sure this will work like this in other Unices. More work is needed here. At any rate, compilation of the C examples work correctly now with: gcc `pkg-config plplot --cflags` x01c.c -o x01c `pkg-config plplot --libs` 2003-10-10 10:45 rlaboiss * include/plConfig.h.in: Removed #undef *_DIR The *_DIR #defines are only needed in plConfg.h, which is included in user programs. These #defines are only needed at build time by the core functions of the PLplot library. Since they are already included in config.h (thanks to the AC_DEFINE_UNQUOTED calls in configure.ac) and this later file is included by plConfig.h at build time, then they can be deleted from plConfig.h.in. 2003-10-09 23:08 airwin * bindings/java/Makefile.am, bindings/java/README.javaAPI, examples/java/Makefile.am, examples/java/README.javademos, test/test_java.sh: Change java install procedure so that CLASSPATH is not required. This solves the configuration problem we were discussing. Also drop all mention of CLASSPATH in the documentation except where relevant; i.e., only at the time when you execute the installed compiled java examples. 2003-10-09 23:02 jcard * configure.ac, include/plConfig.h.in: Create and set BUILD_DIR. 2003-10-09 23:00 jcard * src/plcore.c, src/plctrl.c, bindings/tcl/tclAPI.c: If the current directory is in the build tree, change files search order so as to load them locally. The modifications guarantee that files/drivers/scripts are loaded from the build tree if the current directory is somewhere in the build tree. The objective is that one should be able to change/test/evaluate PLplot without the necessity of installing it; recently this was needed (and for some front ends it still is), requiring the user to have a separate directory to test/change/evaluate PLplot, which means two steps of configure/make, one with the test --prefix and the other with the final one, which is confusing and error prone. Also, for developpers, the make/make install step turns the development cycle sloww and boring. All the compiled front-ends, C, C++ and F77, was tested and work OK with all drivers. The Tcl and Tk front-ends also work OK, but the tk loadable extensions, Pltk and Plplotter, as well as the tcl extension Pltcl, still need adjustments in the pkgIndex.tcl script. The Octave front-end also works OK. Python and Java was not yet tested. This is not yet finish, as some problems might yet appear; however, care has been taken to guarantee that the old behavior still works OK. tclAPI.c: PLbasicInit(): search the init script in the build tree pls_auto_path(): add bindings/tk to auto_path plcore.c: add plInBuildTree() that check if the current directory in within the build source tree plGetDriverDir(): if in the build tree, load the drivers locally plctrl.c: plFindCommand(): if in the build tree, search locally plLibOpenPdfstrm(): if in the build tree, search locally 2003-10-08 19:19 rlaboiss * sysloc.in: Reintroduced deleted AC_MSG_RESULT in Nan awareness test Also, the logic of the test is fixed now. Strangely, the last commit made AC_RUN_IFELSE have only two arguments, instead of three. Besides that, the test must return 1 in case of failure and not 0 as was the case. I did minimal tests, but evrything seems to work now. 2003-10-08 18:37 jcard * sysloc.in: Reformating of "Check for NaN awareness" test, to avoid using another variable. 2003-10-08 17:22 rlaboiss * sysloc.in: Surrounded NaN awareness test with AC_MSG_CHECKING/RESULT Configure shows now: "checking for NaN awareness in C compiler... yes". Please change the message text if it is not appropriate. 2003-10-08 16:51 jcard * sysloc.in: Make test on simple NaN operations libscirocsa/nn can only be compiled if the OS/C compiler is NaN aware. If this test fails they are disabled. For this test to suceed, the correct CFLAGS must be passed to the C compiler. 2003-10-08 16:15 jcard * examples/c/x21c.c: The #, as in #define, should be in the first column, as Compaq C complains. 2003-10-08 15:51 rlaboiss * examples/: c/Makefile.examples.in, c++/Makefile.examples.in: Added CFLAGS and CXXFLAGS The CFLAGS and CXXFLAGS variables have been added to the calls of plplot_libtool in examples/c/Makefile and examples/c++/Makefile, respectively. They get their values from the AC_SUBST variables of same name. 2003-10-08 15:48 rlaboiss * sysloc.in: Added -mieee to CXXFLAGS when neeeded. Setting the CXXFLAGS variable seems to be necessary for compiling the C++ examples on the Alpha architecture, even when the -mieee option is only needed for compiling the libcsirocsa and libcsironn libraries. 2003-10-08 11:17 mlebrun * drivers/: tk.c, tkwin.c, xwin.c: Removed references to plsc -- drivers should use pls, which is passed in. Also minor formatting fixes. 2003-10-07 18:23 rlaboiss * configure.ac: Avoid abortion of configure when python is not found Redefine AC_MSG_ERROR as AC_MSG_WARN around the call to AM_PATH_PYTHON, such that if python is not found, configure will not stop. |
From: Rafael L. <lab...@ps...> - 2003-10-27 09:13:25
|
A new CVS snapshot distribution tarball for PLplot is available at the usual place: http://people.debian.org/~rafael/plplot.html The tarball name is plplot-5.2.1.cvs.20031027.tar.gz. The changes in relation to the last CVS tarball (released one week ago) are quite minimal. The tarball was generated in a Debian unstable system with the following versions of the GNU autotools: Autoconf 2.57 Automake 1.7.8 Libtool 1.5.0a You will find below the changelog of the recent changes in CVS (generated with the command: cvs2cl -l "-d'2003-10-17<'"). Please, test and report. Notice that this tarball will be used in the forthcoming release of the Debian packages. This means that I will abandon the Debian series 5.2.1-* in favor of the 5.2.1.cvs.*-* series. In concrete terms, this means that the Debian packages in the testing distribution will be actually the "release candidates" for the next version of PLplot (probably 5.2.2). The presence of the CVS snapshot version inDebian will help us in the testing cycle of the next release of PLplot. -- Rafael ============== Changelog ============== 2003-10-27 08:48 rlaboiss * debian/rules: Fixed "--with-pthread" -> "--with-pthreads" in call to configure. 2003-10-27 08:46 rlaboiss * scripts/make-cvs-tarball.sh: Made make-cvs-tarball script more robust to premature exit. Added a cleanup function that is called for the trapped signals 0, HUP, QUIT, INT, TERM, and PIPE. This insures that the temporary directory $CVSTMPDIR is removed at exit. Also, a caveat note is added at the comments on the top of the file. 2003-10-26 16:07 rlaboiss * bootstrap.sh: Call aclocal in libltdl directory. This insures that the aclocal.m4 files in both the topdir and the libltdl directory are generated with by same version of Automake and no errors regarding incompatible calls of AM_AUTOMAKE_VERSION will happen. 2003-10-26 05:37 airwin * examples/f77/x05f.fm4: AWI for Arjen Markus plus significant changes of my own as well. Update fifth standard fortran example so it produces results consistent with results for other language interfaces. diff of postscript results showed no difference with c result for example. 2003-10-26 05:23 airwin * examples/f77/x03f.fm4: AWI for Arjen Markus. Minore update of third standard fortran example so it avoids deprecated plcol API and replaces by plcol0 instead. More work required, however, before it will produce results consistent with results for other language interfaces. 2003-10-26 05:17 airwin * examples/f77/x02f.fm4: AWI for Arjen Markus. Update second standard fortran example so it produces results consistent with results for other language interfaces. diff of postscript results showed no difference with c result for example. 2003-10-26 03:55 airwin * examples/f77/: Makefile.am, x17f.fm4, x18f.fm4, x19f.fm4: Initial commit of contributed standard examples from Arjen Markus with some changes by AWI to allow them to compile. x17f and x19f don't link (so must use, e.g, make -k check for now to compile rest of examples) because of missing fortran API. x18f actually links and gives almost the correct standard results for example 18, but "almost" means there is probably an API problem to deal with there. 2003-10-26 02:49 airwin * examples/f77/: Makefile.am, fmacs.m4, x01f.fm4, x02f.fm4, x03f.fm4, x04f.fm4, x05f.fm4, x06f.fm4, x07f.fm4, x08f.fm4, x09f.fm4, x10f.fm4, x11f.fm4, x12f.fm4, x13f.fm4, x16f.fm4: Drop single-precision support for examples for now. I intend to re-instate it later with a sed script. The *.fm4 are now a misnomer (probably the name should be changed to *.fdouble or something, but I have to think about it) since they are no longer processed by m4. Instead, these files are filled by straight double-precision fortran (with no embedded m4 commands) and simply copied to *.f. 2003-10-24 20:31 jcard * configure.ac: Disable dynamic drivers if enable_shared != yes If the user don't want (or the system is not capable of) to build shared libraries, then disable dynamic drivers, as they are dynamically loaded objects. This must to be done after AM_PROG_LIBTOOL. There is a test if test "$enable_dyndrivers" = "yes" above that should, if possible, be put after this test. 2003-10-23 11:48 rlaboiss * debian/: changelog, rules: Debian release 5.2.1-21 From the debian/changelog file: * sysloc.in: Applied patch from upstream CVS that assigns an unversioned path to OCTAVE_OCT_DIR. * debian/rules: - Loosen the restriction on the Octave version dependency, now that OCTAVE_OCT_DIR is unversioned. - Configure with --with-pthreads, such that the xwin driver refreshes the plot when the window is moved or re-exposed. 2003-10-23 09:17 rlaboiss * sysloc.in: Unversioned path for Octave oct dir The OCTAVE_OCT_DIR variable is not versioned anymore (i.e. it does not contain the Octave version 2.*.* in it). This parallels what is done for the OCT_M_DIR variable. OCTAVE_OCT_DIR takes it value from the octave_config_info structure, being either localoctfiledir (for Octave version 2.1.*) or the first component of localoctfilepath (version 2.0.*). The advantage of this change is that the Octave bindings are not tied to a specific version of Octave, and will continue to be visible if the user upgrades Octave. Remember though that there is no guarantee of backward compatibility of the *.oct API within the unstable series of Octave (2.1.*). 2003-10-21 12:22 rlaboiss * drivers/gnome.c: Use HAVE_PTHREAD instead of USE_THREADS This means that pthreads support will be activated in the gnome driver whenever the --with-pthreads option is given to configure. 2003-10-17 15:16 rlaboiss * debian/changelog: Debian release 5.2.1-20 2003-10-17 14:16 rlaboiss * configure.ac: Put AC_CHECK_LIB(ltdl, ...) outside the with_ltdlsystem conditional For some mysterious reason, when the AC_CHECK_LIB was put inside the conditional 'if test "$with_ltdlsystem" = no', configure was failing with the error message: conditional "AMDEP" was never defined. This should be fixed now. Please, test this change. |
From: Arjen M. <arj...@wl...> - 2003-10-27 13:12:34
|
Rafael Laboissiere wrote: > > A new CVS snapshot distribution tarball for PLplot is available at the usual > place: > > http://people.debian.org/~rafael/plplot.html > > The tarball name is plplot-5.2.1.cvs.20031027.tar.gz. The changes in > relation to the last CVS tarball (released one week ago) are quite minimal. > I took this snapshot and created a whole new installation. But when I run the C and FORTRAN examples with xwin as the driver, I get the message: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 10 Current serial number in output stream: 14 Any idea why? (The jpeg driver works without problems and the xterm driver too) Regards, Arjen |
From: Rafael L. <lab...@ps...> - 2003-10-27 18:24:08
|
* Arjen Markus <arj...@wl...> [2003-10-27 14:06]: > I took this snapshot and created a whole new installation. But when I > run the > C and FORTRAN examples with xwin as the driver, I get the message: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 1 (X_CreateWindow) > Serial number of failed request: 10 > Current serial number in output stream: 14 Very strange, indeed. Have any previous tarball worked for you? Could you give more informations on your system and also on your configuration options? -- Rafael |
From: Arjen M. <arj...@wl...> - 2003-10-28 07:56:07
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2003-10-27 14:06]: > > > I took this snapshot and created a whole new installation. But when I > > run the > > C and FORTRAN examples with xwin as the driver, I get the message: > > > > X Error of failed request: BadMatch (invalid parameter attributes) > > Major opcode of failed request: 1 (X_CreateWindow) > > Serial number of failed request: 10 > > Current serial number in output stream: 14 > > Very strange, indeed. Have any previous tarball worked for you? Could you > give more informations on your system and also on your configuration > options? > > -- > Rafael I do not quite remember - I took the official release of PLplot 5.2.1 when I started with this and I am not sure whether the examples worked correctly with the X Window driver (I messed around with the installation so I can not check this anymore). What I do know is that in order to make it work in my own application I had to fiddle a bit with the X Window driver. It turned out that at some deep level the plsc stream was doubly defined - it took me several hours to find this out and it still frightens me at night :D The changes I had to make were: plP_setpxl() and plP_setphy() take an argument pls (instead implicitly using plsc) I will try to see if this is a solution now too. Well, here is the summary: Configure results: command: ./configure --prefix=/p/delft3d/users/markus/plplot-new/plplot-5.2.1 system: i686-pc-linux-gnu have_x: yes prefix: /p/delft3d/users/markus/plplot-new/plplot-5.2.1 CC: gcc CXX: g++ F77: g77 LIB_TAG: d devices: dg300 png jpeg hp7470 hp7580 lj_hpgl imp ljii ljiip mem ntk null pbm plmeta ps psc pstex xterm tek4010 tek4107 mskermit versaterm vlt conex tek4010f tek4107f tk xfig xwin Available device drivers: static: dynamic: dg300.la gd.la hpgl.la impress.la ljii.la ljiip.la mem.la ntk.la null.la pbm.la plmeta.la ps.la pstex.la tek.la tk.la xfig.la xwin.la Compilation options: with_debug: no with_opt: yes with_warn: no with_profile: no Library options: enable_shared: yes enable_static: yes with_rpath: yes with_double: yes Optional libraries: with_qhull: no with_csa: yes with_freetype: yes with_pthreads: no Language Bindings: enable_tcl: yes enable_itcl: yes enable_cxx: yes enable_f77: yes enable_java: no enable_python: no enable_octave: yes Here is the output from uname -a: Linux hydrax 2.4.20 #10 SMP Wed May 14 17:26:48 CEST 2003 i686 unknown glibc: /lib/libc-2.2.5.so gcc: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) Regards, Arjen |
From: Rafael L. <lab...@ps...> - 2003-10-28 08:34:25
|
* Arjen Markus <arj...@wl...> [2003-10-28 08:54]: > What I do know is that in order to make it work in my own application > I had to fiddle a bit with the X Window driver. It turned out that at > some deep level the plsc stream was doubly defined - it took me several > hours to find this out and it still frightens me at night :D > > The changes I had to make were: > plP_setpxl() and plP_setphy() take an argument pls (instead implicitly > using plsc) > > I will try to see if this is a solution now too. If this is a real bug, please try to find the fix again and contribute it. Thanks, -- Rafael |
From: Arjen M. <arj...@wl...> - 2003-10-28 12:46:28
|
Rafael Laboissiere wrote: > > * Arjen Markus <arj...@wl...> [2003-10-28 08:54]: > > > What I do know is that in order to make it work in my own application > > I had to fiddle a bit with the X Window driver. It turned out that at > > some deep level the plsc stream was doubly defined - it took me several > > hours to find this out and it still frightens me at night :D > > > > The changes I had to make were: > > plP_setpxl() and plP_setphy() take an argument pls (instead implicitly > > using plsc) > > > > I will try to see if this is a solution now too. > > If this is a real bug, please try to find the fix again and contribute it. > > Thanks, > > -- > Rafael Hm, I tried to implement my original changes - no effect. :( It happens way before that. After some debugging sessions, I think the problem is that the depth for the main window is not correct. In the debugger I see a depth of 8 (in xwd) whereas XGetGeometry returns a depth of 24! Oh, one other thing: header in InitMain is a string of 80 characters, right now the full name of my program is used and it turns out to be 72 characters ... With one more directory level the buffer would overflow, giving even more mysterious errors. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-10-28 12:54:09
|
Arjen Markus wrote: > > Rafael Laboissiere wrote: > > > > * Arjen Markus <arj...@wl...> [2003-10-28 08:54]: > > > > > What I do know is that in order to make it work in my own application > > > I had to fiddle a bit with the X Window driver. It turned out that at > > > some deep level the plsc stream was doubly defined - it took me several > > > hours to find this out and it still frightens me at night :D > > > > > > The changes I had to make were: > > > plP_setpxl() and plP_setphy() take an argument pls (instead implicitly > > > using plsc) > > > > > > I will try to see if this is a solution now too. > > > > If this is a real bug, please try to find the fix again and contribute it. > > > > Thanks, > > > > -- > > Rafael > > Hm, I tried to implement my original changes - no effect. :( It happens > way before that. > > After some debugging sessions, I think the problem is that the depth > for the main window is not correct. > > In the debugger I see a depth of 8 (in xwd) whereas XGetGeometry returns > a depth of 24! > Yes, that was it: I used the option -drvopt defvis and all worked well! Hm, I think it would be wise to turn that option on by default! Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-10-07 07:50:59
|
Hello all, I promised to look into the FORTRAN versions of the demo programs a while back. Well, here is the overview: Detailed comparison FORTRAN/C: ------------------------------ Demonstration programs in FORTRAN versus the C versions Common differences: - No handling of command-line arguments - Call to plcol0 in C is call to plcol in FORTRAN - Placement of the comments in FORTRAN is not one-to-one with the C version, making comparisons a bit awkward - Sometimes the subroutines/function calls have a different order - Sometimes constants (array-dimensions etc.) have different values x01c/x01f: - No subroutines plot2 and plot3 in x01f - Subroutine plot1 uses different colours (arguments to plcol()) - Call to plwid(1) missing after plot2 - No fonts selected (based on user option) - No "locate mode" (input from mouse/keyboard) - No plot stored in file x02c/x02f: - Call to plwid(j) missing (do-loop 2) - Order pladv/plcol x03c/x03f: - plcol/plcol0 - only difference x04c/x04f: - No subroutine plot1 - freql(i) calculated with 1.0 instead of -2.0 - Call to plwind with arguments 1.0, 6.0 instead of -2.0, 3.0 - Call to plptex (5.0 instead of 1.6) - No switch on type (user option) - No type=0 distinguished at the end x05c/x05f: - Constant 2048 in FORTRAN and 2047 in C - Call to plhist uses this x06c/x06f: - Ordering comments/subroutine calls - Difference in justification of number (10*i) x07c/x07f: - Call to plvpor with different numerical arguments - Ordering of comments x08c/x08f: - Calls to plsurf3d missing - C code distinguishes number of points in X and Y direction (different values too!) - plinit() after initialisation of z array - No distinction rosen/sombrero - No call to plMinMax2dGrid() (or comments regarding this) x09c/x09f: - Little similarity between the two versions x10c/x10f: - No differences x11c/x11f: - Extremely little coherence between the two versions!! x12c/x12f: - FORTRAN version uses C convention for do-loop (1): do 1 i = 0,9 x13c/x13f: - Bizarre diffences in use of reals and integers - Different text strings used - Possible bug in incrementing j (loop 2) x14c: - No FORTRAN equivalent x15c: - No FORTRAN equivalent x16c/x16f: - No likeness between the two versions x17c-x21c: - No FORTRAN equivalent As you can see, some of the demos need a lot of work :( Well, now the next step. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-10-08 08:44:12
|
Hello all, I have run into a bizarre problem under Windows that has an equivalent under Linux (but apparently not the same solution): I need to set a field in the pls structure via a public routine that I added to plcore.c - this is to get the interaction between my program and PLplot correct (my program is supposed to manage the windows and any events, so under Linux I need to inform PLplot about the existing X connection and under Windows I need to something similar). On Linux: I found that using plsc can be troublesome: there seems to be a double pointer plsc - in PLplot plsc points to a different structure than within the driver. I introduced a function "plP_setpxl2" and a function "plP_setphy2" to get around this. On Windows: I get the same type of problem again. The following fragment shows the symptoms: I added the following function (to plcore.c): void plsxwinpixmap(PLINT pixmap_id) { plsc->pixmap_id = pixmap_id ; } This is called from my own program (not from within PLplot). At the end of the routine: pixmap_id = 117507625 plsc->pixmap_id = 0 !!!! pls0.pixmap_id = 1175075625 plsc = 0x00a91c08 pls0 &pls0 = 0x00a91c08 pls0 (&pls0)->pixmap_id = 0 !!!! Now can anyone shed a light here? This goes beyond my comprehension, although I think it is a quirk/bug/flaw in the setup of the libraries (at least, that could be the case on Linux): I use PLplot as an archive/static library the drivers are DLLs/shared libraries The nett effect is: the pls structure does not appear updated once you get into the realm of the actual driver and it creates its own window ... Regards, Arjen |
From: Maurice L. <mj...@ga...> - 2003-10-08 09:08:25
|
Arjen Markus writes: > Hello all, > > I have run into a bizarre problem under Windows that has an equivalent > under Linux (but apparently not the same solution): > > I need to set a field in the pls structure via a public routine that I > added > to plcore.c - this is to get the interaction between my program and > PLplot > correct (my program is supposed to manage the windows and any events, so > under Linux I need to inform PLplot about the existing X connection and > under Windows I need to something similar). > > On Linux: > I found that using plsc can be troublesome: there seems to be a double > pointer plsc - in PLplot plsc points to a different structure than > within > the driver. I introduced a function "plP_setpxl2" and a function > "plP_setphy2" > to get around this. The drivers should never use "plsc", as "pls" is passed in directly. I will fix this shortly. -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: Rafael L. <lab...@ps...> - 2003-10-08 08:55:07
|
[ Moving this thread to plplot-devel. ] * João Cardoso <jc...@fe...> [2003-10-06 16:41]: > -The x21 c++ demos fails with "Floating point exception"; adding -mieee > to the gcc command line solves the problem. The -mieee gcc option is OS > dependent, and is set in sysloc.in (I think) Yes, this is the relevant part of sysloc.in: # ---------------------------------------------------------------------------- # CFLAGS to use ieee because of NaN issues in libcsironn and libcsirocsa # ---------------------------------------------------------------------------- if test "$with_qhull" = "yes" -o "$with_csa" = "yes"; then case "$host_cpu" in i*86 ) CFLAGS="$CFLAGS -mieee-fp" ;; alpha* ) if test "$GCC" = yes; then CFLAGS="$CFLAGS -mieee" else CFLAGS="$CFLAGS -ieee" fi ;; esac fi I am puzzled, since you reported: * João Cardoso <jc...@fe...> [2003-10-06 16:41]: > Under a alphaev6-dec-osf4.0f, with gcc-3.0.3, > > With a plain ./configure --prefix=... From the code above, -mieee must be added to CFLAGS when $host_cpu starts with alpha and gcc is in use. What are we missing here? -- Rafael |
From: <jc...@fe...> - 2003-10-08 09:45:41
|
On Wednesday 08 October 2003 09:54, Rafael Laboissiere wrote: | [ Moving this thread to plplot-devel. ] | | * Jo=E3o Cardoso <jc...@fe...> [2003-10-06 16:41]: | > -The x21 c++ demos fails with "Floating point exception"; adding | > -mieee to the gcc command line solves the problem. The -mieee gcc | > option is OS dependent, and is set in sysloc.in (I think) | | Yes, this is the relevant part of sysloc.in: | | # | --------------------------------------------------------------------- |------- # CFLAGS to use ieee because of NaN issues in libcsironn and | libcsirocsa # | --------------------------------------------------------------------- |------- | | if test "$with_qhull" =3D "yes" -o "$with_csa" =3D "yes"; then | case "$host_cpu" in | i*86 ) | CFLAGS=3D"$CFLAGS -mieee-fp" | ;; | alpha* ) | if test "$GCC" =3D yes; then | CFLAGS=3D"$CFLAGS -mieee" | else | CFLAGS=3D"$CFLAGS -ieee" | fi | ;; | esac | | fi | | I am puzzled, since you reported: | | * Jo=E3o Cardoso <jc...@fe...> [2003-10-06 16:41]: | > Under a alphaev6-dec-osf4.0f, with gcc-3.0.3, | > | > With a plain ./configure --prefix=3D... | | From the code above, -mieee must be added to CFLAGS when $host_cpu | starts with alpha and gcc is in use. What are we missing here? Right now I can't check it, but perhaps it was the c++ demos, and=20 CXXFLAGS should be set. I will check it in a couple of hours. Thanks, Joao |
From: Rafael L. <lab...@ps...> - 2003-10-08 13:52:26
|
* João Cardoso <jc...@fe...> [2003-10-08 10:44]: > Right now I can't check it, but perhaps it was the c++ demos, and > CXXFLAGS should be set. I will check it in a couple of hours. After what you wrote, the bug only shows up in Alpha/GCC when compiling the x21.cc example, which calls griddata. I apparently fixed the problem with my last CVS commits. The -mieee option is now added to CXXFLAGS when it is required for CFLAGS. Besides that, the examples/{c,c++}/Makefile files set now the CFLAGS and CXXFLAGS variables, which are used when invoking plplot_libtool. -- Rafael |
From: Andrew R. <an...@co...> - 2003-10-08 09:06:40
|
It looks like there is a problem with the plplot_libtool here. The C examples are compiled with -mieee-fp defined, but the C++ examples are not. I guess it must be because there is a different libtool rule for C++ code and CFLAGS is not being passed through. I'm afraid I don't know enough about libtool to know where the problem is though. This occurs on my Debian machine as well, it's just that it doesn't actually cause a crash there. Andrew On Wed, Oct 08, 2003 at 10:54:57AM +0200, Rafael Laboissiere wrote: > [ Moving this thread to plplot-devel. ] > > * Jo?o Cardoso <jc...@fe...> [2003-10-06 16:41]: > > > -The x21 c++ demos fails with "Floating point exception"; adding -mieee > > to the gcc command line solves the problem. The -mieee gcc option is OS > > dependent, and is set in sysloc.in (I think) > > Yes, this is the relevant part of sysloc.in: > > # ---------------------------------------------------------------------------- > # CFLAGS to use ieee because of NaN issues in libcsironn and libcsirocsa > # ---------------------------------------------------------------------------- > > if test "$with_qhull" = "yes" -o "$with_csa" = "yes"; then > case "$host_cpu" in > i*86 ) > CFLAGS="$CFLAGS -mieee-fp" > ;; > alpha* ) > if test "$GCC" = yes; then > CFLAGS="$CFLAGS -mieee" > else > CFLAGS="$CFLAGS -ieee" > fi > ;; > esac > > fi > > I am puzzled, since you reported: > > * Jo?o Cardoso <jc...@fe...> [2003-10-06 16:41]: > > > Under a alphaev6-dec-osf4.0f, with gcc-3.0.3, > > > > With a plain ./configure --prefix=... > > >From the code above, -mieee must be added to CFLAGS when $host_cpu starts > with alpha and gcc is in use. What are we missing here? > > -- > Rafael > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <an...@co...> - 2003-10-08 10:05:41
|
On Wed, Oct 08, 2003 at 10:06:35AM +0100, Andrew Ross wrote: > > It looks like there is a problem with the plplot_libtool here. The C > examples are compiled with -mieee-fp defined, but the C++ examples > are not. I guess it must be because there is a different libtool rule > for C++ code and CFLAGS is not being passed through. I'm afraid I > don't know enough about libtool to know where the problem is though. > This occurs on my Debian machine as well, it's just that it doesn't > actually cause a crash there. OK. I've looked a little closer and I think we have two problems. It actually appears to be a makefile and not a libtool issue. 1) When you run "make check" the makefile uses CXXFLAGS instead of CFLAGS for a C++ compilation so we need to alter sysloc.in to add -mieee to CXXFLAGS (and possible in the future FFLAGS as well). 2) When you install the examples and compile them using the installed Makefile (Makefiles.example) then no flags are added at all for any language. I guess we need to ensure that CFLAGS/CXXFLAGS are imported into this makefile and used. Does anyone know how to go about this? Regards Andrew |
From: Rafael L. <lab...@ps...> - 2003-10-08 11:46:44
|
* Andrew Ross <an...@co...> [2003-10-08 10:06]: > It looks like there is a problem with the plplot_libtool here. The C > examples are compiled with -mieee-fp defined, but the C++ examples > are not. I guess it must be because there is a different libtool rule > for C++ code and CFLAGS is not being passed through. Are you talking about examples/c and examples/c++? AFAIK, plplot_libtool is not responsible for passing the C and C++ flags when compiling objects, they must be explicitly given. Indeed, I see here: $ cd examples/c $ make x01c plplot_libtool --mode=link gcc x01c.c -I/usr/include/plplot -L/usr/lib -lplplotd -o x01c mkdir .libs gcc x01c.c -I/usr/include/plplot -o x01c -L/usr/lib /usr/lib/libplplotd.so /usr/lib/libfreetype.so -lz /usr/lib/libcsirocsa.so /usr/lib/libcsironn.so /usr/lib/libqhull.so -lm -ldl $ cd ../c++ $ make x01cc plplot_libtool --mode=link g++ x01cc.cc -I/usr/include/plplot -L/usr/lib -lplplotcxxd -o x01cc g++ x01cc.cc -I/usr/include/plplot -o x01cc -L/usr/lib /usr/lib/libplplotcxxd.so /usr/lib/libplplotd.so /usr/lib/libfreetype.so -lz /usr/lib/libcsirocsa.so /usr/lib/libcsironn.so /usr/lib/libqhull.so -lm -ldl There is no -mieee being passed, neither for compiling the C nor the C++ examples. By the way, this flag is not necessary. The only part of PLplot where they are needed is for compiling the libcsironn and libcsirocsa libraries, which only need a C compiler. This is why the -mieee flag is not added to the CXXFLAGS variable, but only to CFLAGS. > I'm afraid I don't know enough about libtool to know where the problem is > though. This occurs on my Debian machine as well, it's just that it doesn't > actually cause a crash there. Have you had crashes due to -mieee elsewhere than in Debian? -- Rafael |
From: <jc...@fe...> - 2003-10-08 13:32:13
|
On Wednesday 08 October 2003 12:45, Rafael Laboissiere wrote: | * Andrew Ross <an...@co...> [2003-10-08 10:06]: | > It looks like there is a problem with the plplot_libtool here. The | > C examples are compiled with -mieee-fp defined, but the C++ | > examples are not. I guess it must be because there is a different | > libtool rule for C++ code and CFLAGS is not being passed through. | | Are you talking about examples/c and examples/c++? AFAIK, | plplot_libtool is not responsible for passing the C and C++ flags | when compiling objects, they must be explicitly given. Indeed, I see | here: | | $ cd examples/c | $ make x01c | plplot_libtool --mode=link gcc x01c.c -I/usr/include/plplot | -L/usr/lib -lplplotd -o x01c | mkdir .libs | gcc x01c.c -I/usr/include/plplot -o x01c -L/usr/lib | /usr/lib/libplplotd.so /usr/lib/libfreetype.so -lz | /usr/lib/libcsirocsa.so /usr/lib/libcsironn.so /usr/lib/libqhull.so | -lm -ldl | $ cd ../c++ | $ make x01cc | plplot_libtool --mode=link g++ x01cc.cc -I/usr/include/plplot | -L/usr/lib -lplplotcxxd -o x01cc | g++ x01cc.cc -I/usr/include/plplot -o x01cc -L/usr/lib | /usr/lib/libplplotcxxd.so /usr/lib/libplplotd.so | /usr/lib/libfreetype.so -lz /usr/lib/libcsirocsa.so | /usr/lib/libcsironn.so /usr/lib/libqhull.so -lm -ldl | | There is no -mieee being passed, neither for compiling the C nor the | C++ examples. By the way, this flag is not necessary. The only part | of PLplot where they are needed is for compiling the libcsironn and | libcsirocsa libraries, which only need a C compiler. Not quite, as x21c also uses nans, so it must be compiled with a nan aware compiler. | This is why the | -mieee flag is not added to the CXXFLAGS variable, but only to | CFLAGS. But it should. I confirm that compiling x21.cc with -mieee solves the problem. In my sysloc.in I added CXXFLAGS, so I can commit it (latter) unless someone else does it first. Joao PS-I forgot to report that using the native C/F77 compilers under osf works OK. Even the C++ demos, compiled with g++, link/run against the native C compiled library (as it should, but nowadays we must not take anything for granted) | | > I'm afraid I don't know enough about libtool to know where the | > problem is though. This occurs on my Debian machine as well, it's | > just that it doesn't actually cause a crash there. | | Have you had crashes due to -mieee elsewhere than in Debian? |
From: Andrew R. <an...@co...> - 2003-10-08 09:09:04
|
On Mon, Oct 06, 2003 at 04:41:26PM +0100, Jo?o Cardoso wrote: > On Sunday 05 October 2003 01:02, Rafael Laboissiere wrote: > | A new CVS snapshot distribution tarball for PLplot is available at > | the usual place: > | > | http://people.debian.org/~rafael/plplot.html > | > | You will find below the changelog of the recent changes in CVS. > | > | Please, test and report. > > > -After disabling it, a sucessefull make/make install (with only the C, > F77 and C++ bindings) make check (in the build tree) fails with > > x01.cc: In member function `void x01::plot1(int)': > x01.cc:276: `usleep' undeclared (first use this function) > > -and also at > > x17.cc: In constructor `x17::x17(int, char**)': > x17.cc:148: `usleep' undeclared (first use this function) > > the corresponding C demos compile/work ok. > This is a little strange. Can you see what the command line generated by plplot_libtool is in both the C and C++ cases? Maybe this is the same problem as the missing -mieee line because CFLAGS is not being correctly used? It's only a guess. Andrew |
From: Maurice L. <mj...@ga...> - 2003-10-08 09:13:17
|
Andrew Ross writes: > On Mon, Oct 06, 2003 at 04:41:26PM +0100, Jo?o Cardoso wrote: > > On Sunday 05 October 2003 01:02, Rafael Laboissiere wrote: > > | A new CVS snapshot distribution tarball for PLplot is available at > > | the usual place: > > | > > | http://people.debian.org/~rafael/plplot.html > > | > > | You will find below the changelog of the recent changes in CVS. > > | > > | Please, test and report. > > > > > > -After disabling it, a sucessefull make/make install (with only the C, > > F77 and C++ bindings) make check (in the build tree) fails with > > > > x01.cc: In member function `void x01::plot1(int)': > > x01.cc:276: `usleep' undeclared (first use this function) > > > > -and also at > > > > x17.cc: In constructor `x17::x17(int, char**)': > > x17.cc:148: `usleep' undeclared (first use this function) > > > > the corresponding C demos compile/work ok. > > > > This is a little strange. Can you see what the command line generated > by plplot_libtool is in both the C and C++ cases? Maybe this is the > same problem as the missing -mieee line because CFLAGS is not being > correctly used? It's only a guess. I agree, looking at these I don't see what could be wrong -- they are being handled just like the x01c.c and x17c.c demos. -- Maurice LeBrun Lightspeed Semiconductor Corp |
From: <jc...@fe...> - 2003-10-08 14:00:14
|
On Wednesday 08 October 2003 10:12, Maurice LeBrun wrote: | Andrew Ross writes: | > On Mon, Oct 06, 2003 at 04:41:26PM +0100, Jo?o Cardoso wrote: | > > On Sunday 05 October 2003 01:02, Rafael Laboissiere wrote: | > > | A new CVS snapshot distribution tarball for PLplot is | > > | available at the usual place: | > > | | > > | http://people.debian.org/~rafael/plplot.html | > > | | > > | You will find below the changelog of the recent changes in | > > | CVS. | > > | | > > | Please, test and report. | > > | > > -After disabling it, a sucessefull make/make install (with only | > > the C, F77 and C++ bindings) make check (in the build tree) | > > fails with | > > | > > x01.cc: In member function `void x01::plot1(int)': | > > x01.cc:276: `usleep' undeclared (first use this function) | > > | > > -and also at | > > | > > x17.cc: In constructor `x17::x17(int, char**)': | > > x17.cc:148: `usleep' undeclared (first use this function) | > > | > > the corresponding C demos compile/work ok. | > | > This is a little strange. Can you see what the command line | > generated by plplot_libtool is in both the C and C++ cases? Maybe | > this is the same problem as the missing -mieee line because CFLAGS | > is not being correctly used? It's only a guess. | | I agree, looking at these I don't see what could be wrong -- they are | being handled just like the x01c.c and x17c.c demos. There is something indeed strange. plConfig.h defines HAVE_UNISTD_H, and unistd.h defines two flavors of usleep(). The fact is that if I add extern "C" int usleep(useconds_t useconds); or extern "C" void usleep(useconds_t useconds); to x01.cc it compiles and runs OK (with the -xor cmd line option). The relevant unistd.h section: #ifdef _XOPEN_SOURCE_EXTENDED extern int usleep __((useconds_t )); /* spec1170 requires a value to be returned */ #else #ifndef _XOPEN_SOURCE extern void usleep __((unsigned int)); #endif /* _XOPEN_SOURCE */ #endif /* _XOPEN_SOURCE_EXTENDED */ If I compile with -E, no signal of usleep() appears. If I compile with -D_XOPEN_SOURCE_EXTENDED, there is no problem. What to do? Joao |
From: Arjen M. <arj...@wl...> - 2003-10-08 13:17:10
|
Maurice LeBrun wrote: > > Arjen Markus writes: > > Hello all, > > > > I have run into a bizarre problem under Windows that has an equivalent > > under Linux (but apparently not the same solution): > > > > I need to set a field in the pls structure via a public routine that I > > added > > to plcore.c - this is to get the interaction between my program and > > PLplot > > correct (my program is supposed to manage the windows and any events, so > > under Linux I need to inform PLplot about the existing X connection and > > under Windows I need to something similar). > > > > On Linux: > > I found that using plsc can be troublesome: there seems to be a double > > pointer plsc - in PLplot plsc points to a different structure than > > within > > the driver. I introduced a function "plP_setpxl2" and a function > > "plP_setphy2" > > to get around this. > > The drivers should never use "plsc", as "pls" is passed in directly. > I will fix this shortly. > Note, the drivers use "plsc" via plP_setpxl() and the like. My version takes pls as its argument and the rest is just like plP_setpxl(). Now, with a few modifications I have made progress (that is: drawing happens in the window *I* have assigned, rather than in a new one). However, the scaling is awkward, as dev->xScale and dev->yScale are never set or set to odd values. Looking in the code, I see that a bunch of routines are responsible for setting them. (I first thought none of these were called, but that is not true). Okay, I will look into this and report back. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2003-10-08 14:52:18
|
Hello, I have a very crude and very temporary workaround for the problem with xScale and yScale in plD_bop_win3() (win3.cpp). I simply set rect.bottom and rect.right to some value. Now at least the coordinates are in the right order. But, I still do not get a picture. Is there any buffering going on that any of you know about? Note: I circumvent the direct window handling in win3.cpp - maybe something is going on there that I do not get right yet. Regards, Arjen |
From: Rafael L. <lab...@ps...> - 2003-10-30 08:45:20
|
A new CVS snapshot distribution tarball for PLplot is available at the usual place: http://people.debian.org/~rafael/plplot.html The tarball name is plplot-5.2.1.cvs.20031030.tar.gz. The main change in this tarball in respect to the previous one (20031027) is the SOVERSION in configure.ac. The libraries will have (in Linux) the soversion 9 now, instead of 5 as previously. The Debian packages will be renamed as a consequence of this. The tarball was generated in a Debian unstable system with the following versions of the GNU autotools: Autoconf 2.57 Automake 1.7.8 Libtool 1.5.0a You will find below the changelog of the recent changes in CVS (generated with the command: cvs2cl -l "-d'2003-10-27<'"). Please, test and report. We are heading towards the next release of PLplot, and this tarball can be considered as a "pre-candidate-release" one. -- Rafael ============== Changelog ============== 2003-10-29 22:30 rlaboiss * debian/: changelog, control, libplplot9.README.Debian, plplot-gd.files, plplot-gnome.files, plplot-xwin.files, plplot9-driver-gd.files, plplot9-driver-gnome.files, plplot9-driver-xwin.files, rules: Renaming of the driver module Debian packages. The naming changes are: plplot-gd -> plplot9-driver-gd plplot-xwin -> plplot9-driver-xwin plplot-gnome -> plplot9-driver-gnome 2003-10-29 20:40 jcard * examples/tk/xtk01.c, include/plplotP.h, src/pdfutils.c, src/plbox.c, src/plcore.c, src/plfreetype.c, src/plot3d.c, utils/pltcl.c, bindings/tk/Pltk_Init.c, bindings/tk/plframe.c, bindings/tk/plserver.c, bindings/tk-x-plat/Plplotter_Init.c, bindings/tk-x-plat/plplotter.c, drivers/gd.c, drivers/get-drv-info.c, drivers/tk.c, drivers/tkwin.c, drivers/xwin.c, examples/tk/xtk02.c, examples/tk/xtk04.c, bindings/tcl/matrixInit.c, bindings/tcl/tclAPI.c, bindings/tcl/tclMain.c, bindings/tcl/tclMatrix.c, bindings/tk/tcpip.c, bindings/tk/tkMain.c, bindings/tk/tkshell.c: Mostly cosmetic changes that enable plplot to compiled with (almost) no warnings, even with gcc -Wall. Most changes are just casts, and most of them are tcl/tk related. For tcl/tk-8.4, no warnings occurs. Also tested with tcl/tk-8.3, where some warnings remain. There are no java/f77/cxx/python/octave changes. 2003-10-29 20:19 rlaboiss * debian/: changelog, control, libplplot-dev.files, libplplot9.README.Debian, libplplot9.files, octave-plplot.files, plplot-doc.doc-base, plplot-doc.files, plplot-tcl-dev.files, python-plplot.files, rules: Preparation for the next Debian release. From the debian/changelog file: * NOT YET RELEASED! * Preparation for the new upstream version, which changed the soversion of the PLplot library. Changed all the references to libplplot5 to libplplot9. Affected files: - control - libplplot-dev.files - octave-plplot.files - plplot-doc.doc-base - plplot-doc.files - plplot-tcl-dev.files - python-plplot.files - rules - libplplot9.README.Debian (new) - libplplot9.files (new) 2003-10-29 18:24 airwin * examples/f77/Makefile.examples.in: Add examples 15, 17, 18, and 19. Note 17 and 19 don't link properly yet (missing fortran API) so the installed examples will have to be built using make -k. 2003-10-29 17:14 airwin * examples/f77/: x01f.fm4, x04f.fm4, x06f.fm4, x07f.fm4, x08f.fm4, x09f.fm4, x11f.fm4, x12f.fm4, x13f.fm4, x16f.fm4: AWI for Arjen Markus <arj...@wl...> White space changes. 2003-10-29 17:14 airwin * examples/f77/Makefile.am: Add new example 15. 2003-10-29 17:13 airwin * examples/f77/x15f.fm4: AWI for Arjen Markus <arj...@wl...>. Initial commit. This compiles and executes, but there is a problem with the colours which needs debugging. 2003-10-29 15:13 rlaboiss * debian/: changelog, rules: Debian release plplot-5.2.1.cvs.20031027-3. From the debian/changelog file: * debian/rules: - Added symlinks /usr/lib/lib{nn,csa}.so.0, such that this release of the libplplot5 package does not break binary compatiblity with previous released versions of PLplot (closes: #217895). This is an interim solution. Probably, the upstream authors will have to change the soversion or revert the changing of names of the libscsiro{nn,csa} libraries in order to get the problem cleanly fixed. - Call configure with --disable-java, since enable_java has been made the default in the upstream configure.ac. 2003-10-29 14:46 rlaboiss * debian/TODO: Marked all tasks as "DONE". I just realized that this list of ToDo tasks is finished now. I am keeping this file here out of historical interest. 2003-10-29 14:38 rlaboiss * configure.ac: Upgraded SOVERSION to 9:0:0. This is necessary since the recent changes in the naming of the libraries libnn -> libcsironn and libcsa -> libcsirocsa have broke backward binary compatibility for the PLplot library. 2003-10-29 14:10 rlaboiss * examples/c/lena.pgm: Dummy commit to get the sticky -kb option (hopefully). No changes have been made to this file. 2003-10-29 13:47 rlaboiss * debian/control: Changed the build-dependency for GD library. Instead of using the "transitional" package libgd2-dev, use the explicit dependencies to the real packages (libgd2-noxpm-dev | libgd2-xpm-dev). 2003-10-28 17:16 vincentdarley * sys/win-tk/: makePlplotStarkit.tcl, makefile.vc, testPlplot.tcl: win-tk build now works again 2003-10-27 11:54 rlaboiss * debian/: changelog, libplplot-dev.files, libplplot5.README.Debian: Debian release 5.2.1.cvs.20031027-2. From the debian/changelog file: * debian/libplplot-dev.files: Added README.pkg-config file. * debian/libplplot5.README.Debian: Fixed typos. 2003-10-27 11:35 rlaboiss * debian/: changelog, control, libplplot5.README.Debian, rules: Debian release 5.2.1.cvs.20031027-1. From the debian/changelog file: * New CVS snapshot upstream release. This release is actually quite close to the latest Debian 5.2.1-21, since I have been tracking CVS developments since the upstream release 5.2.1. One of biggest advantages of this move is the enourmous reduction in the size of the diff.gz file: du -b plplot*diff* 2686036 ../plplot_5.2.1-21.diff.gz 10198 ../plplot_5.2.1.cvs.20031027-1.diff.gz This huge difference is due to the patched documentation file and the necessity of an uuencoded file for the Debian packages. * debian/rules: Removed all manipulations (targets "build" and "clean") related to the plplot-5.2.1-new-doc.tar.gz.uu file, which is not included in the source package anymore. Also, added flag -k to make distclean. * debian/control: Removed build-dependency on sharutils. * debian/libplplot5.README.Debian: Added note about pkg-config support. 2003-10-27 11:18 rlaboiss * bindings/tk/Makefile.am: Added tclIndex to the CLEANFILES list. 2003-10-27 11:17 rlaboiss * pkgcfg/Makefile.am: Install README file in $(docdir)/README.pkg-config. |