From: Rafael L. <rla...@us...> - 2004-01-26 15:32:00
|
The second release candidate tarball for the forthcoming 5.3.0 release of PLplot is available at: http://people.debian.org/~rafael/plplot.html and also as a File Release at SourceForge. The tarball name is plplot-5.2.1.rc2.5.3.0.tar.gz. It was generated directly from CVS HEAD and includes all the last bug fixes, including Andrew Ross' memory management patches, which fixed all known memory leaks. See the ChangeLog below for details. As usual, Debian packages for unstable (a.k.a. sid) have been uploaded. Please test & report. The final 5.3.0 release is scheduled for the end of January, if no serious show-stopper appears. -- Rafael Laboissiere ==== ChangeLog 5.2.1.rc1.5.3.0 => 5.2.1.rc2.5.3.0 ===== Commit from rlaboiss (2004-01-25 23:21 CET) -------------------- Since on Octave 2.1.53 glob returns a cell array instead of a padded char array, call char() on the result of glob(), such that toggle_plplot_use will work on both Octave 2.1.50 and 2.1.53. Thanks to Brian D. Wright <bdw...@ph...> for the fix. plplot bindings/octave/PLplot/toggle_plplot_use.m 1.6 Commit from rlaboiss (2004-01-25 23:17 CET) -------------------- Call help for plplot_octave_path instead of octave_plplot_path plplot bindings/octave/PLplot/plplot_octave_path.m.in 1.8 Commit from jcard (2004-01-25 19:53 CET) ----------------- Fix help message. plplot bindings/octave/PLplot/set_view.m 1.11 Commit from jcard (2004-01-25 19:52 CET) ----------------- Fix usage message. Slightly mouse behavior change. plplot bindings/octave/demos/x01c.m 1.9 Commit from jcard (2004-01-25 19:48 CET) ----------------- Fix usage messages. plplot bindings/octave/demos/x14c.m 1.8 Commit from rlaboiss (2004-01-25 15:37 CET) -------------------- [ RL for AWI: ] The include directories aren't specified quite correctly in bindings/python/Makefile.am. AM_CPPFLAGS = $(INCLTDL) -I/$(PYTHON_INC_DIR) -I/$(PYTHON_NUM_DIR) $(X_CFLAGS) should be replaced by AM_CPPFLAGS = $(INCLTDL) -I$(PYTHON_INC_DIR) -I$(PYTHON_NUM_DIR) $(X_CFLAGS) The first way puts a double slash in the result (since both PYTHON_INC_DIR and PYTHON_NUM_DIR already have a leading slash). This double slash confuses the Cygwin compiler and shouldn't be there anyway. plplot bindings/python/Makefile.am 1.25 Commit from rlaboiss (2004-01-25 15:32 CET) -------------------- Put the install-data-hook rule outside the enable_cxx conditional. Configure --disable-cxx should work now. plplot examples/c++/Makefile.am 1.14 Commit from rlaboiss (2004-01-25 15:28 CET) -------------------- Removed the install-data-hook rule from inside the with_pkg_config conditional. Instead, Use the conditional inside the -hook rule. This pattern have been used already in other Makefile.am files in PLplot. plplot pkgcfg/Makefile.am 1.11 Commit from rlaboiss (2004-01-25 15:24 CET) -------------------- Use "+=" automake construct to set SUBDIR. Code is now cleaner and nicer. plplot lib/Makefile.am 1.9 Commit from rlaboiss (2004-01-25 15:08 CET) -------------------- Exclude from EXTRA_DIST the *.sh files that are generated by AC_OUTPUT. plplot test/Makefile.am 1.12 Commit from rlaboiss (2004-01-25 15:04 CET) -------------------- Produce a unified diff in cvs commit messages CVSROOT loginfo 1.64 Commit from rlaboiss (2004-01-25 15:02 CET) -------------------- Dummy commit, please ignore plplot acinclude.m4 1.14 plplot bootstrap.sh 1.29 Commit from rlaboiss (2004-01-25 14:52 CET) -------------------- Added build instruction notes for the Mac OS X (Fink). Thanks to Koen van der Drift <kvd...@ea...>. plplot INSTALL 1.11 Commit from airwin (2004-01-25 05:01 CET) ------------------ Update to remove solved problems, and document new problems which have surfaced because of our more extensive cross-platform testing. plplot PROBLEMS 1.25 Commit from rlaboiss (2004-01-24 18:29 CET) -------------------- Dummy commit plplot bootstrap.sh 1.28 Commit from rlaboiss (2004-01-24 18:27 CET) -------------------- Use syncmail instead of dncvspipe for commit notifications. CVSROOT loginfo 1.63 Commit from andrewross (2004-01-23 16:00 CET) ---------------------- Fix plend() to check the library is initialised before trying to clear up. plplot src/plcore.c 1.125 Commit from airwin (2004-01-23 07:06 CET) ------------------ PHI and THETA statement functions must have integer arguments according to solaris native f95 compiler. g77 doesn't care and gives the identical result. plplot examples/f77/x18f.fm4 1.6 Commit from airwin (2004-01-23 05:48 CET) ------------------ Account for two variations of BIG_ENDIAN symbol in system headers. #elif defined(BIG_ENDIAN) ==> #elif defined(BIG_ENDIAN) || defined(_BIG_ENDIAN) plplot sysloc.in 1.71 plplot lib/csa/nan.h 1.3 plplot lib/nn/nan.h 1.3 Commit from rlaboiss (2004-01-22 23:32 CET) -------------------- Synched HEAD and v5_3_0 plplot debian/changelog 1.69.2.2 plplot debian/control 1.43.2.1 Commit from rlaboiss (2004-01-22 23:30 CET) -------------------- * debian/control: Removed most of the Conflicts/Replaces/Provides fields, since they where legacies from the libplplot5 packages. The libplplot9 and libplplot5 still cannot co-exist (although this is only of theoretical interest, since there are no other packages in Debian that depend on libplplot5). plplot debian/changelog 1.71 plplot debian/control 1.44 Commit from rlaboiss (2004-01-22 22:52 CET) -------------------- RL for Arjen Markus <arj...@wl...>: applied patch for DLL examples (branch v5_3_0). plplot sys/win32/msdev/DExamples/DExamples.mak 1.1.16.2 Commit from rlaboiss (2004-01-22 22:51 CET) -------------------- Added year 2004 for Copyright holders AWI and RL. plplot doc/docbook/src/plplotdoc.xml.in 1.33 Commit from rlaboiss (2004-01-22 22:49 CET) -------------------- RL for Arjen Markus <arj...@wl...>: applied patch for DLL examples. plplot sys/win32/msdev/DExamples/DExamples.mak 1.3 Commit from rlaboiss (2004-01-22 22:03 CET) -------------------- Added rpm spec file for Mandrake 9.2 (contributed by Brian D. Wright <bdw...@ph...>) + plplot rpm/plplot_mandrake9.2.spec 1.1 Commit from jcard (2004-01-22 04:04 CET) ----------------- Check that the event (key/mouse button) is printable. A Octave-2.1.50 behaviour change in is isprint() plplot bindings/octave/demos/x01c.m 1.8 Commit from jcard (2004-01-22 03:41 CET) ----------------- Close the slave window before ending, otherwise it will be left around. plplot bindings/octave/demos/x14c.m 1.7 Commit from rlaboiss (2004-01-21 23:17 CET) -------------------- Changed boolean operation OR from element-by-element to short-circuit (as it was intended to be, originally). This was causing an error in Octave 2.1.50. plplot bindings/octave/PLplot/plplot_octave_path.m.in 1.7 Commit from airwin (2004-01-21 22:33 CET) ------------------ Make fortran test for command-line parsing more parallel with actual code in bindings/fortran/configurable.f.in. In particular use implicit none and explicitly type iargc. plplot configure.ac 1.154 Commit from airwin (2004-01-21 22:30 CET) ------------------ The iargc intrinsic must be explicitly typed for certain fortran compilers for the implicit none case. This change is not required by g77, but g77 still works with it. plplot bindings/f77/configurable.f.in 1.4 Commit from airwin (2004-01-21 22:27 CET) ------------------ lnblnk and rand intrinsics require specific typing for certain compilers for the implicit none case. This change is not required by g77, but g77 still works with it. plplot examples/f77/x01f.fm4 1.14 plplot examples/f77/x17f.fm4 1.6 Commit from airwin (2004-01-20 03:25 CET) ------------------ Tighten up memory managment for C examples 18 and 21. plplot examples/c/x18c.c 1.21 plplot examples/c/x21c.c 1.12 Commit from airwin (2004-01-20 03:03 CET) ------------------ Plot a contour only if the number of points in the contour is greater than zero. This fix takes care of some memory management issues (use of uninitialized values) turned up by valgrind for example 21. plplot src/plot3d.c 1.54 Commit from airwin (2004-01-20 00:10 CET) ------------------ Tighten memory management for C examples 1-16. plplot examples/c/x08c.c 1.41 plplot examples/c/x09c.c 1.25 plplot examples/c/x11c.c 1.22 plplot examples/c/x14c.c 1.23 plplot examples/c/x16c.c 1.25 Commit from airwin (2004-01-19 21:11 CET) ------------------ Resolved conflict. Also, original patch was slightly wrong npoints ==> points plplot lib/nn/delaunay.c 1.5 Commit from airwin (2004-01-19 21:07 CET) ------------------ AWI for Andrew Ross. Memory management fixes. The C++ examples were a bit lax in freeing allocated memory. These changes ensure all allocations are paired up with a suitable delete or Free2dGrid call. plplot examples/c++/x01.cc 1.8 plplot examples/c++/x01cc.cc 1.10 plplot examples/c++/x02.cc 1.5 plplot examples/c++/x03.cc 1.4 plplot examples/c++/x04.cc 1.5 plplot examples/c++/x05.cc 1.5 plplot examples/c++/x06.cc 1.4 plplot examples/c++/x07.cc 1.4 plplot examples/c++/x08.cc 1.6 plplot examples/c++/x09.cc 1.4 plplot examples/c++/x10.cc 1.4 plplot examples/c++/x11.cc 1.4 plplot examples/c++/x12.cc 1.4 plplot examples/c++/x13.cc 1.4 plplot examples/c++/x14.cc 1.6 plplot examples/c++/x15.cc 1.4 plplot examples/c++/x16.cc 1.5 plplot examples/c++/x17.cc 1.5 plplot examples/c++/x18.cc 1.4 plplot examples/c++/x19.cc 1.4 plplot examples/c++/x20.cc 1.5 plplot examples/c++/x21.cc 1.5 Commit from airwin (2004-01-19 20:17 CET) ------------------ AWI for Andrew Ross memory management cleanup. Change plInitDispatchTable() to properly initialize driver counts, Change plend() so that it properly frees dispatch table memory, and allows the PLplot library to be reinitialized if you want to start over without exiting your application. plplot src/plcore.c 1.124 Commit from jcard (2004-01-19 20:14 CET) ----------------- plmap(): Close map file after use, as per Andrew Ross patch plplot src/plmap.c 1.16 Commit from jcard (2004-01-19 20:12 CET) ----------------- delaunay_destroy(): free d->points, allocated in delaunay_build() and never released, as per Andrew Ross patch. plplot lib/nn/delaunay.c 1.4 Commit from airwin (2004-01-19 20:10 CET) ------------------ AWI for Andrew Ross memory management cleanup. Add #ifndef ENABLE_DYNDRIVERS ... #endif about the lines in plD_dispatch_init_XXXXX which assign pdt->pl_MenuStr and pdt->pl_DevName. If this is a dynamic driver then we have already assigned these strings in plcore.c using the database. We absolutely don't want to use a static string in the dynamic driver to initialise it with since that string will disappear once the driver is unloaded and we are left with no valid driver name or menu item. Oh and overwriting the string will also leak the previously allocated memory for the names. plplot drivers/cgm.c 1.11 plplot drivers/dg300.c 1.23 plplot drivers/gd.c 1.33 plplot drivers/gnome.c 1.31 plplot drivers/hpgl.c 1.16 plplot drivers/impress.c 1.25 plplot drivers/linuxvga.c 1.15 plplot drivers/ljii.c 1.32 plplot drivers/ljiip.c 1.19 plplot drivers/mem.c 1.2 plplot drivers/ntk.c 1.10 plplot drivers/null.c 1.23 plplot drivers/pbm.c 1.13 plplot drivers/plmeta.c 1.41 plplot drivers/ps.c 1.62 plplot drivers/pstex.c 1.17 plplot drivers/tek.c 1.50 plplot drivers/tk.c 1.83 plplot drivers/tkwin.c 1.20 plplot drivers/xfig.c 1.34 plplot drivers/xwin.c 1.118 |
From: Michel P. <Mic...@en...> - 2004-01-27 07:17:47
|
I tested the new tarfile on my Mac (OSX 10.3) with the following commands: export CFLAGS=-Wno-long-double export FLIBS='-L/sw/lib -lfrtbegin -lSystem' ./configure --prefix=/usr/local/plplot.rc2.5.3.0 make make install Everything went smoothly. I could compile the fortran tests with the commands such as: export PATH="/usr/local/plplot.rc2.5.3.0/bin:$PATH make x01f Therefore I think that the INSTALL file can be simplified to mention only these commands and not the F77="g77 -lcc_dynamic" that I had to use previously. For me the current release seems perfectly operational (of course I use only a subset of all plplot possibilities: fortran, postscript and xwindows drivers essentially). This is a big progress with respect to previous versions of plplot. Michel |
From: Rafael L. <rla...@us...> - 2004-01-27 08:26:39
|
* Michel Peyrard <Mic...@en...> [2004-01-27 08:18]: > I tested the new tarfile on my Mac (OSX 10.3) with the following > commands: > > export CFLAGS=-Wno-long-double > export FLIBS='-L/sw/lib -lfrtbegin -lSystem' > ./configure --prefix=/usr/local/plplot.rc2.5.3.0 > make > make install > > Everything went smoothly. Thanks for this valuable report, Michel. It seems that RC2 will become the final 5.3.0 tarball without many changes. The scheduled date for the release is Jan 31 / Feb 1. An aside note: I deleted the old v5_3_0 branch and recreated it from HEAD yesterday, so you can continue to use HEAD for new experiments. The sources for the RC2 tarball are tagged v5_3_0_rc2 in CVS. From now on, if something that you committ to HEAD must absolutely go into the final tarball, please drop me a note. -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-27 14:29:03
|
On Jan 26, 2004, at 10:31 AM, Rafael Laboissiere wrote: > The tarball name is plplot-5.2.1.rc2.5.3.0.tar.gz. It was generated > directly from CVS HEAD and includes all the last bug fixes, including > Andrew > Ross' memory management patches, which fixed all known memory leaks. > See > the ChangeLog below for details. > Is it the same that was already available on Sunday - or did you upload a new one with those last bug fixes? In the former case, no problems on Mac OS X. If the latter, I need to redownload it and try it out later. - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-27 16:33:53
|
* Koen van der Drift <kvd...@ea...> [2004-01-27 09:28]: > Is it the same that was already available on Sunday - or did you upload a > new one with those last bug fixes? In the former case, no problems on Mac > OS X. If the latter, I need to redownload it and try it out later. This is probably my mistake. At any rate, it only affected the Octave bindings. The files changed between the two "releases" are: bindings/octave/demos/x14c.m bindings/octave/demos/x01c.m bindings/octave/PLplot/set_view.m bindings/octave/PLplot/plplot_octave_path.m.in bindings/octave/PLplot/toggle_plplot_use.m -- Rafael |
From: Rafael L. <rla...@us...> - 2004-01-27 17:37:51
|
* Rafael Laboissiere <rla...@us...> [2004-01-27 17:16]: > * Koen van der Drift <kvd...@ea...> [2004-01-27 09:28]: > > > Is it the same that was already available on Sunday - or did you upload a > > new one with those last bug fixes? In the former case, no problems on Mac > > OS X. If the latter, I need to redownload it and try it out later. > > This is probably my mistake. At any rate, it only affected the Octave > bindings. The files changed between the two "releases" are: > > bindings/octave/demos/x14c.m > bindings/octave/demos/x01c.m > bindings/octave/PLplot/set_view.m > bindings/octave/PLplot/plplot_octave_path.m.in > bindings/octave/PLplot/toggle_plplot_use.m I forgot to say that I already uploaded the real 5.2.1.rc2.5.3.0 tarball to http://people.debian.org/~rafael/plplot.html Sorry for this confusion. The File Release at SF is the good one, though. -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-27 21:02:43
|
On Jan 27, 2004, at 12:37 PM, Rafael Laboissiere wrote: > I forgot to say that I already uploaded the real 5.2.1.rc2.5.3.0 > tarball to > http://people.debian.org/~rafael/plplot.html > > Sorry for this confusion. The File Release at SF is the good one, > though. > So what's the one that's now on your page with the word 'orig' in it? thanks, - Koen. |
From: Rafael L. <rla...@us...> - 2004-01-27 23:00:34
|
* Koen van der Drift <kvd...@ea...> [2004-01-27 16:02]: > So what's the one that's now on your page with the word 'orig' in it? It is another mistake. Fixed now. -- Rafael |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-28 13:01:38
|
On Jan 27, 2004, at 5:59 PM, Rafael Laboissiere wrote: > * Koen van der Drift <kvd...@ea...> [2004-01-27 16:02]: > >> So what's the one that's now on your page with the word 'orig' in it? > > It is another mistake. Fixed now. > That one worked fine as well - no problems compiling. - Koen. |
From: Alan W. I. <ir...@be...> - 2004-01-27 18:19:22
|
On 2004-01-27 17:16+0100 Rafael Laboissiere wrote: > * Koen van der Drift <kvd...@ea...> [2004-01-27 09:28]: > > > Is it the same that was already available on Sunday - or did you upload a > > new one with those last bug fixes? In the former case, no problems on Mac > > OS X. If the latter, I need to redownload it and try it out later. > > This is probably my mistake. At any rate, it only affected the Octave > bindings. The files changed between the two "releases" are: > > bindings/octave/demos/x14c.m > bindings/octave/demos/x01c.m > bindings/octave/PLplot/set_view.m > bindings/octave/PLplot/plplot_octave_path.m.in > bindings/octave/PLplot/toggle_plplot_use.m It turns out this is an important difference. Ullal reported to me, and I just confirmed that x01c.m hangs (100 per cent cpu usage) indefinitely with RC2 (actually cvs HEAD in my case). The only way out was to ctrl-c. I just locally reinstated the version (x01c.m version 1.8 from cvs) from my prior extensive tests on the weekend, and the indefinite hang disappears. I have octave 2.1.35 and Ullal has octave 2.1.49. The purpose of the x standard examples according to Joao's posts explaining the octave version support is to exercise the low-level octave interface to PLplot in a way that can be used by both octave 2.0 (which we haven't tested), old versions of octave (2.1.49 or less), and of course the latest versions of octave 2.1.50 and above. test_octave.sh specifically excludes the higher-level p examples because they demand octave-2.1.50 or above. But now it appears one of those (octave-2.1.50 or above) constructs has appeared in x01c.m causing an indefinite hang on older octave systems. So I see two choices here: ** revert x01c.m back to version 1.8 or update the latest so that all versions of octave can run the x examples. I will be happy to run tests here to make sure the results do work for octave 2.1.35, but I guess we will be unable to do any tests for versions older than that. ** specifically declare you do not support octave versions below 2.1.50. (and put in a ./configure test enforcing octave-2.1.50 or above). I don't care which choice you make so long as one of them is made. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2004-01-27 20:11:52
|
On Tuesday 27 January 2004 18:19, Alan W. Irwin wrote: | On 2004-01-27 17:16+0100 Rafael Laboissiere wrote: | > * Koen van der Drift <kvd...@ea...> [2004-01-27 09:28]: | > > Is it the same that was already available on Sunday - or did you | > > upload a new one with those last bug fixes? In the former case, | > > no problems on Mac OS X. If the latter, I need to redownload it | > > and try it out later. | > | > This is probably my mistake. At any rate, it only affected the | > Octave bindings. The files changed between the two "releases" are: | > | > bindings/octave/demos/x14c.m | > bindings/octave/demos/x01c.m | > bindings/octave/PLplot/set_view.m | > bindings/octave/PLplot/plplot_octave_path.m.in | > bindings/octave/PLplot/toggle_plplot_use.m | | It turns out this is an important difference. | | Ullal reported to me, and I just confirmed that x01c.m hangs (100 per | cent cpu usage) indefinitely with RC2 (actually cvs HEAD in my case). | The only way out was to ctrl-c. I just locally reinstated the | version (x01c.m version 1.8 from cvs) from my prior extensive tests | on the weekend, and the indefinite hang disappears. | | I have octave 2.1.35 and Ullal has octave 2.1.49. The purpose of the | x standard examples according to Joao's posts explaining the octave | version support is to exercise the low-level octave interface to | PLplot in a way that can be used by both octave 2.0 (which we haven't | tested), old versions of octave (2.1.49 or less), and of course the | latest versions of octave 2.1.50 and above. test_octave.sh | specifically excludes the higher-level p examples because they demand | octave-2.1.50 or above. But now it appears one of those | (octave-2.1.50 or above) constructs has appeared in x01c.m Not at all. There is nothing in x01c.m specific to 2.1.50. I'm compiling rc2 with octave-2.0.17 to debug the problem. Just finish and no problem at all. Did you read the message? You are in Locate mode. Click any mouse button or press any key and a printout will give you some info. Please keep <NumLock> and <CapsLock> off. Terminate with the <Enter> key. Dont't forget to finish the plot with the <Enter> or <ESC> key It's not perfect, feel free to change. To end locate mode press the enter key. To end the plot press the enter or esc key. Joao PS-BUT I *had* problems linking plplot_octave with octave-2.0.17: I ended linking manually using the following cmd: [jcard@feup] LD_RUN_PATH=/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/src/.libs:/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/nn/.libs/:/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/csa/.libs mc++ -shared -o plplot_octave.oct plplot_octave.o -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/src/.libs -lplplotd -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/csa/.libs -lcsirocsa -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/nn/.libs -lcsironn mc++ is gcc-2.95.3, needed to compile Octave-2.0.17 The Makefile cmd does: [jcard@feup] rm plplot_octave.oct [jcard@feup] make plplot_octave.oct LD_RUN_PATH=../../src/.libs:../../lib/csa/.libs:../../lib/nn/.libs \ mkoctfile-2.0.17 -v -I. plplot_octave.cc -L../../src/.libs -lplplotd `../../scripts/get-dependency-libs.sh ../../src/.libs/libplplotd.la` mc++ -c -fPIC -I/usr/local/include/octave-2.0.17 -I/usr/local/include/octave-2.0.17/octave -I/usr/local/include -mieee-fp -fno-rtti -fno-exceptions -fno-implicit-templates -O2 -I. plplot_octave.cc -o plplot_octave.o mc++ -shared -o plplot_octave.oct plplot_octave.o -L../../src/.libs -lplplotd -L/usr/lib/gcc-lib/i486-suse-linux/3.3/../../.. -lfreetype -L/usr/lib -lz -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/csa -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/csa/.libs -lcsirocsa -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/nn -L/home/jcard/tmp/plplot-5.2.1.rc2.5.3.0/lib/nn/.libs -lcsironn -lqhull -lm -ldl /usr/bin/ld: plplot_octave.oct: undefined versioned symbol name __dynamic_cast@@CXXABI_1.2 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status make: *** [plplot_octave.oct] Error 1 Why? I don't know. BTW, an unwanted behaviour comes back: the compilation occurs when only linking is necessary Joao | causing an | indefinite hang on older octave systems. | | So I see two choices here: | | ** revert x01c.m back to version 1.8 or update the latest so that all | versions of octave can run the x examples. I will be happy to run | tests here to make sure the results do work for octave 2.1.35, but I | guess we will be unable to do any tests for versions older than that. | | ** specifically declare you do not support octave versions below | 2.1.50. (and put in a ./configure test enforcing octave-2.1.50 or | above). | | I don't care which choice you make so long as one of them is made. | | 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 PLplot scientific plotting software | package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), | the Loads of Linux Links project (loll.sf.net), and the Linux | Brochure Project (lbproject.sf.net). | __________________________ | | Linux-powered Science | __________________________ | | | ------------------------------------------------------- | The SF.Net email is sponsored by EclipseCon 2004 | Premiere Conference on Open Tools Development and Integration | See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. | http://www.eclipsecon.org/osdn | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2004-01-27 21:18:54
|
On 2004-01-27 20:12-0000 Jo=E3o Cardoso wrote: > Not at all. There is nothing in x01c.m specific to 2.1.50. I'm > compiling rc2 with octave-2.0.17 to debug the problem. > > Just finish and no problem at all. Did you read the message? > > You are in Locate mode. Click any mouse button or press any key > and a printout will give you some info. > Please keep <NumLock> and <CapsLock> off. Terminate with the <Enter> > key. > Dont't forget to finish the plot with the <Enter> or <ESC> key > > It's not perfect, feel free to change. To end locate mode press the > enter key. To end the plot press the enter or esc key. I should not have jumped to the conclusion that it was version related, and I should have been more specific. I was not trying to run x01c.m interactively. (I don't know how to do that in any case). Instead, I am running the test script plplot-test.sh (which calls test_octave.sh). That test script hangs indefinitely with 100 per cent cpu usage with the RC2 version of x01c.m. If I copy the RC1 version of x01c.m the problem disappears. Can you confirm that hang for plplot-test.sh? I suspect that now also occu= r for the latest octave as well (which I cannot test, of course, but you, Brian, and Rafael have access to it). It is possible some interactive stuff has been put into x01c.m for RC2 whic= h makes it impossible to run it with -dev psc (which is what test_octave.sh attempts to do). If this is the problem, can you change x01c.m to work onc= e again with file devices? Of course, it would be good if you would remove that irrelevant message "You are in Locate mode...." for the non-interactive, file device case as well since the other versions of this standard example don't print out such a message for non-interactive devices= =2E I hope you are also able to sort out the linking problem you found for octave-2.0.17. In my opinion, that is a separate but release-critical mkoctfile issue that should be resolved before release or else octave-2.0.x should be excluded for the release. 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-01-27 23:57:36
|
* Alan W. Irwin <ir...@be...> [2004-01-27 13:18]: > Can you confirm that hang for plplot-test.sh? > > It is possible some interactive stuff has been put into x01c.m for RC2 which > makes it impossible to run it with -dev psc (which is what test_octave.sh > attempts to do). If this is the problem, can you change x01c.m to work once > again with file devices? I confirm it here for RC2. Also, when the old RC1 x01c.m is used, the hang disappears. The patch to fix this problem is quite trivial: --- x01c.m-orig 2004-01-27 23:46:39.000000000 +0000 +++ x01c.m 2004-01-27 23:45:31.000000000 +0000 @@ -103,7 +103,9 @@ if (status != 0) printf("wx=%.3f wy=%.3f dx=%.3f dy=%.3f c=0x%02x str=%s mb=%d mod=%0x swin=%d\n", ... wX, wY, dX, dY, keysym, string, button, mod, swin); - endif + else + break; + endif fflush(stdout); endwhile Joao, if you agree with the patch above, I will apply it for the final tarball. > I suspect that now also occur for the latest octave as well (which I cannot > test, of course, but you, Brian, and Rafael have access to it). I tried plplot-test.sh with Octave 2.1.53 on Debian stable and it fails for x03c.m: error: dimension mismatch in argument x error: called from `plline' error: evaluating for command near line 44, column 3 error: called from `x03c' in file `/var/tmp/examples/octave/x03c.m' error: evaluating for command near line 4, column 1 This is a 2.1.53-specific problem. We should not bother fixing it pre-release, but we should put a note saying that the Octave PLplot bindings will not fully work for version > 2.1.50. > I hope you are also able to sort out the linking problem you found for > octave-2.0.17. In my opinion, that is a separate but release-critical > mkoctfile issue that should be resolved before release or else octave-2.0.x > should be excluded for the release. I vote for the second option. We should not hold the release just because there are version-specific problems with OCtave. -- Rafael |
From: <jc...@fe...> - 2004-01-28 03:36:01
|
On Tuesday 27 January 2004 23:56, Rafael Laboissiere wrote: | * Alan W. Irwin <ir...@be...> [2004-01-27 13:18]: | > Can you confirm that hang for plplot-test.sh? | > | > It is possible some interactive stuff has been put into x01c.m for RC2 | > which makes it impossible to run it with -dev psc (which is what | > test_octave.sh attempts to do). If this is the problem, can you change | > x01c.m to work once again with file devices? | | I confirm it here for RC2. Also, when the old RC1 x01c.m is used, the | hang disappears. | | The patch to fix this problem is quite trivial: | | --- x01c.m-orig 2004-01-27 23:46:39.000000000 +0000 | +++ x01c.m 2004-01-27 23:45:31.000000000 +0000 | @@ -103,7 +103,9 @@ | if (status != 0) | printf("wx=%.3f wy=%.3f dx=%.3f dy=%.3f c=0x%02x str=%s mb=%d | mod=%0x swin=%d\n", ... wX, wY, dX, dY, keysym, string, button, mod, swin); | - endif | + else | + break; | + endif | | fflush(stdout); | endwhile | | Joao, if you agree with the patch above, I will apply it for the final | tarball. Sure, I was only attempting to do what you considered (in another thread) to be a more intuitive behaviour. Oddly I can't get the <esc> key status to be reported, but this also happens in x01c.c. The code in x01c.c that checks for PLK_Escape is not working, because plGetCursor returns gin.keysym=0, instead of PLK_Escape. This happens because in xwin.c:LocateKey() plGinInit() is called *after* PLK_Escape is detected, setting all the gin structure elements to 0. I don't know what was the rational for this change, but as it is now we should clean all x01c like demos of the PLK_Escape code, because being an example can lead to user confusion. But please commit your change, the PLK_Escape issue must be corrected post-release. | > I suspect that now also occur for the latest octave as well (which I | > cannot test, of course, but you, Brian, and Rafael have access to it). | | I tried plplot-test.sh with Octave 2.1.53 on Debian stable and it fails | for x03c.m: | | error: dimension mismatch in argument x | error: called from `plline' | error: evaluating for command near line 44, column 3 | error: called from `x03c' in file `/var/tmp/examples/octave/x03c.m' | error: evaluating for command near line 4, column 1 | | This is a 2.1.53-specific problem. And rises incompatibilities issues, I guess that a lot of users will complain if this is going to be the default behaviour. You see, where Octave used to create column vectors, now it creates row vectors! Only a few x??c.c scripts run OK. I will wait and see. | We should not bother fixing it | pre-release, but we should put a note saying that the Octave PLplot | bindings will not fully work for version > 2.1.50. | | > I hope you are also able to sort out the linking problem you found for | > octave-2.0.17. In my opinion, that is a separate but release-critical | > mkoctfile issue that should be resolved before release or else | > octave-2.0.x should be excluded for the release. | | I vote for the second option. We should not hold the release just because | there are version-specific problems with OCtave. Please notice that the link step was sucesseful when only nn/csa was specified in the link cmd; when all set of libraries that plplot depends on (freetype, qhull, etc) was specified, the link failed. So the problem is not mkoctfile but the libs added to it. I don't have the time to fix it, feel free to disable octave. Thanks Joao |
From: Rafael L. <rla...@us...> - 2004-01-28 09:34:27
|
* João Cardoso <jc...@fe...> [2004-01-28 03:35]: > | Joao, if you agree with the patch above, I will apply it for the final > | tarball. > > Sure, I was only attempting to do what you considered (in another thread) to > be a more intuitive behaviour. CVS committed. > | This is a 2.1.53-specific problem. > > And rises incompatibilities issues, I guess that a lot of users will > complain if this is going to be the default behaviour. You see, where > Octave used to create column vectors, now it creates row vectors! Only a > few x??c.c scripts run OK. I will wait and see. Unfortunately, Octave 2.1 is a moving target. > | I vote for the second option. We should not hold the release just because > | there are version-specific problems with OCtave. > > Please notice that the link step was sucesseful when only nn/csa was specified > in the link cmd; when all set of libraries that plplot depends on (freetype, > qhull, etc) was specified, the link failed. So the problem is not mkoctfile > but the libs added to it. > > I don't have the time to fix it, feel free to disable octave. Okay, since so many problems are popping up, I will disable Octave by default in configure.ac. Is this okay with everybody? -- Rafael |
From: Brian D. W. <bdw...@ph...> - 2004-01-28 05:17:08
|
Hi Rafael, Recall that after figuring out the issue with the numlock key (I changed x01c.m to try to compensate for the weird behavior when it is on!), I suggested to Joao that you revert back to the earlier version since it behaves like the C version and only do the line change: if (gin.keysym < hex2dec("FF") && isprint(char(gin.keysym))) instead of if (gin.keysym < hex2dec("FF") && isprint(gin.keysym)) in the original x01c.m. I ran through all the interactive octave tests again and the only issues I had were that the usual notions of buttons 2 and 3 were reversed for p17 and p18. Also the box around the legends is generally too small in the "p" demos. Brian On Wed, 28 Jan 2004, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-01-27 13:18]: > > > Can you confirm that hang for plplot-test.sh? > > > > It is possible some interactive stuff has been put into x01c.m for RC2 which > > makes it impossible to run it with -dev psc (which is what test_octave.sh > > attempts to do). If this is the problem, can you change x01c.m to work once > > again with file devices? > > I confirm it here for RC2. Also, when the old RC1 x01c.m is used, the hang > disappears. > > The patch to fix this problem is quite trivial: > > --- x01c.m-orig 2004-01-27 23:46:39.000000000 +0000 > +++ x01c.m 2004-01-27 23:45:31.000000000 +0000 > @@ -103,7 +103,9 @@ > if (status != 0) > printf("wx=%.3f wy=%.3f dx=%.3f dy=%.3f c=0x%02x str=%s mb=%d mod=%0x swin=%d\n", ... > wX, wY, dX, dY, keysym, string, button, mod, swin); > - endif > + else > + break; > + endif > > fflush(stdout); > endwhile > > Joao, if you agree with the patch above, I will apply it for the final > tarball. > > > I suspect that now also occur for the latest octave as well (which I cannot > > test, of course, but you, Brian, and Rafael have access to it). > > I tried plplot-test.sh with Octave 2.1.53 on Debian stable and it fails for > x03c.m: > > error: dimension mismatch in argument x > error: called from `plline' > error: evaluating for command near line 44, column 3 > error: called from `x03c' in file `/var/tmp/examples/octave/x03c.m' > error: evaluating for command near line 4, column 1 > > This is a 2.1.53-specific problem. We should not bother fixing it > pre-release, but we should put a note saying that the Octave PLplot bindings > will not fully work for version > 2.1.50. > > > I hope you are also able to sort out the linking problem you found for > > octave-2.0.17. In my opinion, that is a separate but release-critical > > mkoctfile issue that should be resolved before release or else octave-2.0.x > > should be excluded for the release. > > I vote for the second option. We should not hold the release just because > there are version-specific problems with OCtave. > > -- ====================================================================== Brian D. Wright Tel: (415)476-1007 Dept. of Physiology, Box 0444 Fax: (415)476-4929 Keck Center for Integrative Neuroscience bdw...@ph... University of California, San Francisco 513 Parnassus Avenue San Francisco, CA 94143-0444 ====================================================================== |
From: Rafael L. <rla...@us...> - 2004-01-28 09:38:20
|
* Brian D. Wright <bdw...@ph...> [2004-01-27 21:16]: > Recall that after figuring out the issue with the numlock key > (I changed x01c.m to try to compensate for the weird behavior when it is > on!), I suggested to Joao that you revert back to the earlier version > since it behaves like the C version and only do the line change: > if (gin.keysym < hex2dec("FF") && isprint(char(gin.keysym))) > instead of > if (gin.keysym < hex2dec("FF") && isprint(gin.keysym)) > in the original x01c.m. > > I ran through all the interactive octave tests again > and the only issues I had were that the usual notions of buttons > 2 and 3 were reversed for p17 and p18. Also the box around the legends is > generally too small in the "p" demos. Thanks for your report, Brian. The problems above will be fixed post-release. -- Rafael |
From: Arjen M. <arj...@wl...> - 2004-01-28 12:42:02
|
Hello, I am trying to use more than 16 colours in color map 0. At first, the picture came out all in black instead of coloured and then I saw a myriad of messages about "color map 0 hosed". This happens in rdbuf_state(). It checks if the colour index exceeds 15 or not. I have temporarily excluded this error message and the resetting of the index to 1 (hence the black colour), but shouldn't the check be: if ( (int) icol0 >= pls->ncol0 ) { ... } Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-01-28 14:29:46
|
Hello, I am running into a strange problem (on Windows) that has to do with opening and closing multiple windows with a graph produced by PLplot. As long as I keep the _first_ window open that has graphics in it, all subsequent windows are correctly drawn. But as soon as the first window is closed, any windows that are opened after that or are resized and therefore redrawn, are shown in a uniform colour... Any thoughts on where to find the cause? (It is not the buffering, I have turned that off for the moment). Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-01-28 17:17:49
|
On 2004-01-28 15:29+0100 Arjen Markus wrote: > Hello, > > I am running into a strange problem (on Windows) that has to do with > opening and closing multiple windows with a graph produced by PLplot. > > As long as I keep the _first_ window open that has graphics in it, > all subsequent windows are correctly drawn. But as soon as the > first window is closed, any windows that are opened after that > or are resized and therefore redrawn, are shown in a uniform colour... > > Any thoughts on where to find the cause? (It is not the buffering, > I have turned that off for the moment). IIRC, the windows device is based on the Linux/Unix -dev xwin so I would like to run some tests with -dev xwin under Linux to make sure we don't have the same colour problem in that case. If you did the same on the Linux systems available to you, it might give you a useful benchmark to compare to your windows results. Is there application code you could post to the list (or a standard example you could point out) that has the peculiar colour behaviour for the windows device? 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 PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2004-01-29 18:00:32
|
On Wed, Jan 28, 2004 at 09:17:41AM -0800, Alan Irwin wrote: > On 2004-01-28 15:29+0100 Arjen Markus wrote: > > > Hello, > > > > I am running into a strange problem (on Windows) that has to do with > > opening and closing multiple windows with a graph produced by PLplot. > > > > As long as I keep the _first_ window open that has graphics in it, > > all subsequent windows are correctly drawn. But as soon as the > > first window is closed, any windows that are opened after that > > or are resized and therefore redrawn, are shown in a uniform colour... > > > > Any thoughts on where to find the cause? (It is not the buffering, > > I have turned that off for the moment). > > IIRC, the windows device is based on the Linux/Unix -dev xwin so I would > like to run some tests with -dev xwin under Linux to make sure we don't have > the same colour problem in that case. If you did the same on the Linux > systems available to you, it might give you a useful benchmark to compare to > your windows results. > > Is there application code you could post to the list (or a standard example > you could point out) that has the peculiar colour behaviour for the windows > device? There doesn't seem to be the same problem with the xwin driver - at least not in my quick test. I've hacked together a version of x01.cc which plots two sets of the same plots at the same time. The windows all refresh and resize ok except when one of the windows is waiting in plend() for return to be pressed to close the window. In that case only that window is refreshed. I guess this is expected behaviour. With pthreads disabled then the windows don't refresh properly until plend() is called, but again that's expected. Hope this helps narrow down the problem. If you want my little test program to try under windows then let me know. Andrew |
From: Arjen M. <arj...@wl...> - 2004-01-30 16:41:50
|
Hello Alan, Andrew, others, sorry to bother you, but I do not get any mails back that I send to the mailing list. I have no idea where this is coming from. Any one noticed this too? Regards, Arjen |
From: Koen v. d. D. <kvd...@ea...> - 2004-01-30 22:58:00
|
On Jan 30, 2004, at 4:12 AM, Arjen Markus wrote: > sorry to bother you, but I do not get any mails back that > I send to the mailing list. I have no idea where this is > coming from. > sourceforge is constipated. - Koen. |
From: Arjen M. <arj...@wl...> - 2004-01-30 17:52:48
|
Hm, do I get my mails or not? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-01-31 00:04:16
|
Andrew Ross wrote: > > > Hope this helps narrow down the problem. If you want my little test > program to try under windows then let me know. > I have tried all the tricks that I knew or could think of. Nothing helped or evn showed me the way to go. Instead, I am now using a workaround: the first window with graphics that is opened is not closed and destroyed but instead it is hidden. This works - I am not completely convinced this will be acceptable, but at least it allows me to go on. Regards, Arjen |