From: Alan W. I. <ir...@be...> - 2003-04-15 21:05:13
|
I was just able to find some time to test RC1 on my Debian woody system. Sadly, it does not give a well-tested impression. I was really relying on the rest of you to do some extensive checks for tcl/tk and octave, but it appears those have not been done in even a superficial manner. For a number of good reasons I really am scaling back my testing role to superficial checks that anybody can do on their own system, and somebody else here has to take up the slack if we are going to have a quality product. That said, I have fixed the obvious stuff. If in addition, Rafael or Joao can fix the p16 octave example (and anything else that shows up for a complete octave test), then I think Rafael should go ahead with RC2 early tomorrow (Wednesday). Here is what I did: ./configure --prefix=/usr/local/plplot_at --enable-java --disable-static --with-prebuiltdoc >& configure.out make; make install A superficial check of the various kinds of installed documentation went well. plplot-test.sh built psc and plmeta files with no obvious problems (other than an obvious pladv ordering bug in x21c which I have just fixed). I was able to do some minimal tcl/tk testing as well (although Maurice and Geoffrey should be responsible for most of that testing). *** Simple wish and tclsh tests following the directions in README.tcldemos and README.tkdemos don't work in RC1 because there is a problem for bindings/*/pkgIndex.tcl.in. Those scripts assume the library suffix is the same as VERSION (true at the time I introduced those scripts, but not any longer). To solve this I have introduced LIBRARY_VERSION = numerical suffix of the library in configure.ac which must be adjusted to be consistent with SOVERSION. Rafael, can you find an automatic way of keeping LIBRARY_VERSION consistent with SOVERSION? That's important because otherwise we have a tcl/tk maintenance issue that will come back to haunt us every time SOVERSION is changed. I did look for any variable that was already set to the numerical library suffix, but I couldn't find any. *** There was one nasty RC1 failure for the combination of octave and png device. Opened p16.png.01 *** PLPLOT WARNING *** plsfam: Must be called before plinit. *** PLPLOT WARNING *** plsdev: Must be called before plinit. Plplot library version: 5.2.1.rc1 followed by a whole bunch of garbage output. This should have easily been found with even superficial octave testing unless there is some platform difference between me on the one hand and Joao and Rafael on the other. Rafael and Joao, what are your results for ./plplot-test.sh --device=png ( or ./plplot-test.sh --front-end=octave --device=png) for RC1. If they verify this problem I suspect it is due to some recent change to p16 that does something out of order since that example worked before for me with png. Warnings. I did notice some warnings along the way. configure still outputs the following: configure: WARNING: itclDecls.h: present but cannot be compiled configure: WARNING: itclDecls.h: check for missing prerequisite headers? configure: WARNING: itclDecls.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug...@gn.... ## configure: WARNING: ## ------------------------------------ ## This is a symptom of the poor state of our unix/linux tcl/tk configuration. I wanted to replace that configuration, but I didn't feel right attempting that since I am no tcl/tk expert. I noticed, however, that the tclConfig.sh that comes with tcl8.3 is deprecated and it is not immediately obvious how to use it with autotools. Its suggested replacement, tcl.m4 is supposed to fit in with autotools, but it needs an m4/autoconf expert to look at it to see if it is consistent with the current generation of autotools. (I suspect it is not from all the name clashes I see.) Whether that is a post or pre-release issue really depends on how well our current tcl/tk configuration works cross-platform. Maurice and Geoffrey, does the current tcl/tk configuration work okay on all Linux/Unix platforms accessible to you? Here are some compiler warnings that I noticed: * plplotcmodule_double.c:684: warning: PySequence_Fast_GET_ITEM' redefined //usr/include/python2.1/abstract.h:902: warning: this is the location of the previous definition I believe this is a swig issue that we have no control over (except to try later swig versions post-release and send in bug reports to swig if the issue is still there). * /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.35 -I/usr/include/octave-2.1.35/ octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -I. plplot_octave.cc -o plplot_octave.o In file included from /usr/include/octave-2.1.35/octave/oct.h:31, from plplot_octave.cc:11: /usr/include/octave-2.1.35/octave/config.h:148: warning: HAVE_ISINF' redefined ../../config.h:36: warning: this is the location of the previous definition /usr/include/octave-2.1.35/octave/config.h:151: warning: HAVE_ISNAN' redefined ../../config.h:39: warning: this is the location of the previous definition /usr/include/octave-2.1.35/octave/config.h:288: warning: HAVE_FINITE' redefined ../../config.h:24: warning: this is the location of the previous definition /usr/include/octave-2.1.35/octave/config.h:474: warning: HAVE_USLEEP' redefined ../../config.h:101: warning: this is the location of the previous definition Rafael or Joao may want to deal with these warnings before the release. * Whole host of tk-x-plat/plplotter.c warnings. IIRC, Vince said those disappear if you use a version of tcl that is later than 8.3. Alternatively, these symptoms may be a result of our iffy tcl/tk configuration. That (and a quick check of RC2 for the above issues) is about all the testing I have time for before the release so again, somebody else is going to have to step forward if you want a quality 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Maurice L. <mj...@ga...> - 2003-04-15 21:17:59
|
Alan W. Irwin writes: > I did notice some warnings along the way. configure still outputs the > following: > > configure: WARNING: itclDecls.h: present but cannot be compiled > configure: WARNING: itclDecls.h: check for missing prerequisite headers? > configure: WARNING: itclDecls.h: proceeding with the preprocessor's result > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to bug...@gn.... ## > configure: WARNING: ## ------------------------------------ ## AFAIK this is harmless. Just irritating. :) > This is a symptom of the poor state of our unix/linux tcl/tk configuration. > I wanted to replace that configuration, but I didn't feel right attempting > that since I am no tcl/tk expert. I noticed, however, that the tclConfig.sh > that comes with tcl8.3 is deprecated and it is not immediately obvious how > to use it with autotools. Its suggested replacement, tcl.m4 is supposed to > fit in with autotools, but it needs an m4/autoconf expert to look at it to > see if it is consistent with the current generation of autotools. (I > suspect it is not from all the name clashes I see.) Whether that is a post > or pre-release issue really depends on how well our current tcl/tk > configuration works cross-platform. Maurice and Geoffrey, does the current > tcl/tk configuration work okay on all Linux/Unix platforms accessible to > you? I believe so. Sorry I've been MIA as of late, but have been swampt. In addition I will be taking a much needed vacation from tomorrow until Sunday. I *will* try to give the latest RC at least a cursory check on both RH7.3 and Solaris. As for the tcl config problems, I will look into it but it will take some time. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
From: Rafael L. <lab...@ps...> - 2003-04-15 22:09:25
|
* Alan W. Irwin <ir...@be...> [2003-04-15 14:03]: > *** Simple wish and tclsh tests following the directions in README.tcldemos > and README.tkdemos don't work in RC1 because there is a problem for > bindings/*/pkgIndex.tcl.in. Those scripts assume the library suffix is the > same as VERSION (true at the time I introduced those scripts, but not any > longer). To solve this I have introduced LIBRARY_VERSION = numerical > suffix of the library in configure.ac which must be adjusted to be > consistent with SOVERSION. Rafael, can you find an automatic way of keeping > LIBRARY_VERSION consistent with SOVERSION? That's important because > otherwise we have a tcl/tk maintenance issue that will come back to haunt > us every time SOVERSION is changed. I did look for any variable that was > already set to the numerical library suffix, but I couldn't find any. I dislike this solution for two reason reason. the first, as you mention above, is the maintenance burden that it introduces. The second (and more important) reason is that your assumption of library suffix generation does not work cross-platform. If I remember correctly, in HPUX (for instance) when SOVERSION=8:0:3, then the library would be something like libplplot.sl.8.3. There are other system with even more exotic rule and the assumption that it will be libplplot.5.3.0 is far from being the rule. > Rafael and Joao, what are your results for > ./plplot-test.sh --device=png > ( or ./plplot-test.sh --front-end=octave --device=png) for RC1. $ ./plplot-test.sh --front-end=octave --device=png [removed warnings about automatic_replot]Opened p1.png Opened p2.png Opened p3.png Opened p4.png Opened p5.png Opened p6.png Opened p7.png Opened p8.png Opened p9.png Opened p13.png Opened p15.png Opened p16.png Plplot library version: 5.2.0.cvs.20030415 Opened x01o.png [removed mouse click message] Opened x02o.png Opened x03o.png Opened x04o.png Opened x05o.png Opened x06o.png Opened x07o.png Opened x08o.png Opened x09o.png Opened x10o.png Opened x11o.png Opened x12o.png Opened x13o.png Opened x15o.png Opened x16o.png Opened x18o.png > * /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.35 > -I/usr/include/octave-2.1.35/ > octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -I. > plplot_octave.cc > -o plplot_octave.o > In file included from /usr/include/octave-2.1.35/octave/oct.h:31, > from plplot_octave.cc:11: > /usr/include/octave-2.1.35/octave/config.h:148: warning: > HAVE_ISINF' redefined > ../../config.h:36: warning: this is the location of the previous definition > /usr/include/octave-2.1.35/octave/config.h:151: warning: HAVE_ISNAN' redefined > ../../config.h:39: warning: this is the location of the previous definition > /usr/include/octave-2.1.35/octave/config.h:288: warning: HAVE_FINITE' > redefined > ../../config.h:24: warning: this is the location of the previous definition > /usr/include/octave-2.1.35/octave/config.h:474: warning: HAVE_USLEEP' > redefined > ../../config.h:101: warning: this is the location of the previous definition > > Rafael or Joao may want to deal with these warnings before the release. Joao and I agreed that these are totally harmless warnings. As Maurice uses to say, they are just irritating. In sum, I am not going to fix this before the release. > That (and a quick check of RC2 for the above issues) is about all the > testing I have time for before the release so again, somebody else is going > to have to step forward if you want a quality release. It seems that most of the problems that you found are quite minor or even negligeable for now (besides that LIBRARY_VERSION bizareness). I think that we are pretty close to a "quality release". -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-04-16 02:00:23
|
On Tue, 15 Apr 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-04-15 14:03]: > > > *** Simple wish and tclsh tests following the directions in README.tcld= emos > > and README.tkdemos don't work in RC1 because there is a problem for > > bindings/*/pkgIndex.tcl.in. Those scripts assume the library suffix is= the > > same as VERSION (true at the time I introduced those scripts, but not a= ny > > longer). To solve this I have introduced LIBRARY_VERSION =3D numerical > > suffix of the library in configure.ac which must be adjusted to be > > consistent with SOVERSION. Rafael, can you find an automatic way of kee= ping > > LIBRARY_VERSION consistent with SOVERSION? That's important because > > otherwise we have a tcl/tk maintenance issue that will come back to hau= nt > > us every time SOVERSION is changed. I did look for any variable that w= as > > already set to the numerical library suffix, but I couldn't find any. > > I dislike this solution for two reason reason. the first, as you mention > above, is the maintenance burden that it introduces. The second (and mor= e > important) reason is that your assumption of library suffix generation do= es > not work cross-platform. If I remember correctly, in HPUX (for instance) > when SOVERSION=3D8:0:3, then the library would be something like > libplplot.sl.8.3. There are other system with even more exotic rule and = the > assumption that it will be libplplot.5.3.0 is far from being the rule. I also agree with your second point (as you will see from my configure.ac notes). However, this is just a quick fix to at least get plplot to work under wish and tclsh for Linux, and the quick fix might even work for some unices such as solaris. We obviously need a more fundamental solution here= , but that needs a tcl/tk expert to step in. The simple problem being solved here is that wish and tclsh need to know th= e _complete_ PLplot library names so they can load them. Maurice, I wonder i= f you could use the libtool results $prefix/lib/lib*.la to find the complete library names that wish and tclsh need? For example, the libplplotd versio= n of this file installed on my system has the following line: library_names=3D'libplplotd.so.5.3.0 libplplotd.so.5 libplplotd.so' and similarly for libplplottcltkd library_names=3D'libplplottcltkd.so.5.3.0 libplplottcltkd.so.5 libplplottcl= tkd.so' If solaris lib*.la files have something similar, Maurice or Geoffry might b= e able to come up with a good cross-platform way to deal with this issue in pkgIndex.tcl(.in) using the tcl equivalent of grep and cut to obtain the first library name mentioned in the list. Because Maurice is going on vacation, this might be worth delaying the release for a few days. > > > Rafael and Joao, what are your results for > > ./plplot-test.sh --device=3Dpng > > ( or ./plplot-test.sh --front-end=3Doctave --device=3Dpng) for RC1. > > $ ./plplot-test.sh --front-end=3Doctave --device=3Dpng > [removed warnings about automatic_replot]Opened p1.png > Opened p2.png > Opened p3.png > Opened p4.png > Opened p5.png > Opened p6.png > Opened p7.png > Opened p8.png > Opened p9.png > Opened p13.png > Opened p15.png > Opened p16.png > Plplot library version: 5.2.0.cvs.20030415 > Opened x01o.png > [removed mouse click message] > Opened x02o.png > Opened x03o.png > Opened x04o.png > Opened x05o.png > Opened x06o.png > Opened x07o.png > Opened x08o.png > Opened x09o.png > Opened x10o.png > Opened x11o.png > Opened x12o.png > Opened x13o.png > Opened x15o.png > Opened x16o.png > Opened x18o.png Well, I certainly do _not_ get those results on Debian woody. It appears w= e have now found two bugs. The result you have above is completely incorrect because there is no familying. I have no idea why this bug shows up for your system. Does this occur just for octave? Could you give the =2E/plplot-test.sh --front-end=3Dc --device=3Dpng results as well? There s= hould be many pages for most of the x examples, yet it appears you only have one. If the lack of familying persists for the C front end for device=3Dpng, the= n please have a look at the plplot-test.sh script to see what is going on. If it only occurs for octave, then somehow octave is not getting the familying parameter passed to it correctly on your Debian testing version platform, while that works fine on Debian woody. Very strange indeed! Here is the complete Debian woody result. It _does_ have the proper familying (note the different style of file names and the multiple pages fo= r some examples), but it also dies horribly during p16 (Rafael would probably see this as well if familying were being correctly turned on for his case). =2E/plplot-test.sh --front-end=3Doctave --device=3Dpng warning: It is recommended that you set 'automatic_replot=3D1' in your ~/.octaverc file. warning: in /usr/local/plplot_at/share/plplot_octave/figure.m near line 59,= column 7: >>> warning ("It is recommended that you set 'automatic_replot=3D1' \n\t i= n your ~/.octaverc file."); Opened p1.png.01 Opened p2.png.01 Opened p3.png.01 Opened p4.png.01 Opened p5.png.01 Opened p6.png.01 Opened p7.png.01 Opened p7.png.02 Opened p8.png.01 Opened p8.png.02 Opened p9.png.01 Opened p13.png.01 Opened p15.png.01 Opened p15.png.02 Opened p16.png.01 *** PLPLOT WARNING *** plsfam: Must be called before plinit. *** PLPLOT WARNING *** plsdev: Must be called before plinit. Plplot library version: 5.2.1.rc1 (AWI comment added. I think the above two warning messages are the key to = the p16 problem). Plotting Options: < 1> xwin X-Window (Xlib) < 2> tk Tcl/TK Window < 3> xterm Xterm Window < 4> tekt Tektronix Terminal (4010) < 5> tek4107t Tektronix Terminal (4105/4107) < 6> mskermit MS-Kermit emulator < 7> versaterm Versaterm vt100/tek emulator < 8> vlt VLT vt100/tek emulator < 9> conex Conex vt320/tek emulator <10> dg300 DG300 Terminal <11> plmeta PLplot Native Meta-File <12> tekf Tektronix File (4010) <13> tek4107f Tektronix File (4105/4107) <14> ps PostScript File (monochrome) <15> psc PostScript File (color) <16> xfig Fig file <17> ljiip LaserJet IIp/deskjet compressed graphics <18> ljii LaserJet II Bitmap File (150 dpi) <19> hp7470 HP 7470 Plotter File (HPGL Cartridge, Small Plotter) <20> hp7580 HP 7580 Plotter File (Large Plotter) <21> lj_hpgl HP Laserjet III, HPGL emulation mode <22> imp Impress File <23> pbm PDB (PPM) Driver <24> png PNG file <25> jpeg JPEG file <26> pstex Combined Postscript/LaTeX files <27> null Null device <28> ntk New tk driver <29> cgm CGM file <30> mem User-supplied memory device <31> tkwin New tk driver Enter device number or keyword: Invalid device: =AC=E1=FF=BF=D3&=CB@=D0=C67 This message is repeated many times before.... *** PLPLOT ERROR *** plSelectDev: Too many tries. Program aborted Invalid device: =AC=E1=FF=BF=D3&=CB@=D0=C6 Because of the two messages about plinit, I think there is an ordering prob= lem in p16 which has been recently introduced. Joao, can you replicate this bug or has familying disappeared in your environment as well? > It seems that most of the problems that you found are quite minor or even > negligeable for now (besides that LIBRARY_VERSION bizareness). I think t= hat > we are pretty close to a "quality release". Well, I hope you are right. Certainly, I think only modest changes are required to get to a quality release. But "the devil is in the details". The biggest problem known at this time is the bizarre lack of familying on Rafael's Debian platform. That really kills all png results for at least octave (if not the other front ends as well depending on the results of Rafael's additional familying tests.) There is also what I hope is a minor ordering issue with p16 for octave. Rafael, I now think you should hold off on RC2 until at least these two issues are resolved, and furthermore we may want to delay the final release by a few days depending on what Maurice says about the wish/tclsh library finding problem. 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 affiliation with the PLplot scientific plotting software packag= e (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-04-16 03:07:47
|
On Wednesday 16 April 2003 02:59, Alan W. Irwin wrote: | On Tue, 15 Apr 2003, Rafael Laboissiere wrote: | > * Alan W. Irwin <ir...@be...> [2003-04-15 14:03]: ... | Because of the two messages about plinit, I think there is an ordering | problem in p16 which has been recently introduced. Joao, can you replicate | this bug or has familying disappeared in your environment as well? Opened p1.png.01 Opened p2.png.01 Opened p3.png.01 Opened p4.png.01 Opened p5.png.01 Opened p6.png.01 Opened p7.png.01 Opened p7.png.02 Opened p8.png.01 Opened p8.png.02 Opened p9.png.01 Opened p13.png.01 Opened p15.png.01 Opened p15.png.02 Opened p16.png.01 Opened p21.png.01 Joao |
From: Alan W. I. <ir...@be...> - 2003-04-16 03:43:55
|
On Wed, 16 Apr 2003, Joao Cardoso wrote: > On Wednesday 16 April 2003 02:59, Alan W. Irwin wrote: > | On Tue, 15 Apr 2003, Rafael Laboissiere wrote: > | > * Alan W. Irwin <ir...@be...> [2003-04-15 14:03]: > ... > > | Because of the two messages about plinit, I think there is an ordering > | problem in p16 which has been recently introduced. Joao, can you replicate > | this bug or has familying disappeared in your environment as well? > > Opened p1.png.01 > Opened p2.png.01 > Opened p3.png.01 > Opened p4.png.01 > Opened p5.png.01 > Opened p6.png.01 > Opened p7.png.01 > Opened p7.png.02 > Opened p8.png.01 > Opened p8.png.02 > Opened p9.png.01 > Opened p13.png.01 > Opened p15.png.01 > Opened p15.png.02 > Opened p16.png.01 > Opened p21.png.01 Thanks very much for that additional information. Both familying and p16 are obviously working for Joao, but since he cannot reproduce either bug for RC1, it makes it much tougher to figure out how to get familying working for Rafael's environment, and p16 for my environment. 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-04-16 07:58:44
Attachments:
p
|
* Alan W. Irwin <ir...@be...> [2003-04-15 18:59]: > I also agree with your second point (as you will see from my configure.ac > notes). However, this is just a quick fix to at least get plplot to work > under wish and tclsh for Linux, and the quick fix might even work for some > unices such as solaris. We obviously need a more fundamental solution here, > but that needs a tcl/tk expert to step in. Do not count on me. I never wrote a single line of Tcl in my life... > The simple problem being solved here is that wish and tclsh need to know > the _complete_ PLplot library names so they can load them. Maurice, I > wonder if you could use the libtool results $prefix/lib/lib*.la to find the > complete library names that wish and tclsh need? For example, the > libplplotd version of this file installed on my system has the following > line: > > library_names='libplplotd.so.5.3.0 libplplotd.so.5 libplplotd.so' and > > similarly for libplplottcltkd > > library_names='libplplottcltkd.so.5.3.0 libplplottcltkd.so.5 libplplottcltkd.so' > > If solaris lib*.la files have something similar, Maurice or Geoffry might be > able to come up with a good cross-platform way to deal with this issue in > pkgIndex.tcl(.in) using the tcl equivalent of grep and cut to obtain the > first library name mentioned in the list. Because Maurice is going on > vacation, this might be worth delaying the release for a few days. What you re proposing is reasonable and does not seem difficult to implement. However, I am reluctant to do it, since my knowledge of Tcl/Tk is exactly equal to zero and am not willing to improve this situation before the release. > Well, I certainly do _not_ get those results on Debian woody. It appears we > have now found two bugs. The result you have above is completely incorrect > because there is no familying. Sorry, I was doing something wrong yesterday. I did in my computer at home (inaccessible right now), and I cannot tell now what the difference is. As a matter of fact, I can reproduce here the bug yuo found. My guess is that text_octave.sh is doing things in the wrong way, by calling plplot_stub only once and then looping over the p??.m files. Now, each file needs a different way of being initialized and then the clash happens in p16.m. In other words, the bug is in test_octave.sh! I propose the patch attached below. The loop is done at the shell level and octave is called individually for each demo file. It is much slower, but it works. Joao and Alan: do you agree with the patch? > Rafael, I now think you should hold off on RC2 until at least these two > issues are resolved, and furthermore we may want to delay the final release > by a few days depending on what Maurice says about the wish/tclsh library > finding problem. The test_octave.sh problem is a non-bug, and can be "fixed". The Tcl/Tk one is a real problem. It is just too irritating that we should delay the release because of it, but I think we have no choice. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-04-16 15:14:33
|
On Wed, 16 Apr 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]: > > The simple problem being solved here is that wish and tclsh need to know > > the _complete_ PLplot library names so they can load them. Maurice, I > > wonder if you could use the libtool results $prefix/lib/lib*.la to find the > > complete library names that wish and tclsh need? For example, the > > libplplotd version of this file installed on my system has the following > > line: > > > > library_names='libplplotd.so.5.3.0 libplplotd.so.5 libplplotd.so' and > > > > similarly for libplplottcltkd > > > > library_names='libplplottcltkd.so.5.3.0 libplplottcltkd.so.5 libplplottcltkd.so' > > > > If solaris lib*.la files have something similar, Maurice or Geoffry might be > > able to come up with a good cross-platform way to deal with this issue in > > pkgIndex.tcl(.in) using the tcl equivalent of grep and cut to obtain the > > first library name mentioned in the list. Because Maurice is going on > > vacation, this might be worth delaying the release for a few days. > > What you re proposing is reasonable and does not seem difficult to > implement. However, I am reluctant to do it, since my knowledge of Tcl/Tk > is exactly equal to zero and am not willing to improve this situation before > the release. I am virtually in the same boat. (I can stumble my way through a tcl script by constant reference to the man pages, but that is about it.) So this is just one suggestion for Maurice and Geoffrey as a cross-platform way out of this. However, if they find the current LIBRARY_VERSION kludge works on solaris for running plplot under wish and tclsh, then that is probably good enough for now. > > > Well, I certainly do _not_ get those results on Debian woody. It appears we > > have now found two bugs. The result you have above is completely incorrect > > because there is no familying. > > Sorry, I was doing something wrong yesterday. I did in my computer at home > (inaccessible right now), and I cannot tell now what the difference is. Please follow up on this; it may well be a bug in plplot-test.sh that you have found. If you run that script you should *always* get familying for png: See case $device in png) dsuffix=png export dsuffix options="-fam -fflen 2" export options ;; But your results were as if the -fam option never got propagated to test_octave.sh so apparently you have found a way to clobber options which I would like to see fixed. > As > a matter of fact, I can reproduce here the bug yuo found. That's a great relief that we are finally on the same page! > > My guess is that text_octave.sh is doing things in the wrong way, by calling > plplot_stub only once and then looping over the p??.m files. Now, each file > needs a different way of being initialized and then the clash happens in > p16.m. > > In other words, the bug is in test_octave.sh! That is certainly possible. But before we deal with that, let's look at simpler examples. What is your result for the simple octave example I put together that showed the bug yesterday? First, do you confirm it, and second do you and Joao feel that you should not call a p example more than once after plsetopt and figure? I looked at those results a bit more, and it seems that p16 overwrites whatever file is open killing the previous p example's plot. But p7 and the rest I tried do not have this behaviour. It is possible p16 has _always_ overwritten the previous plot when in familying mode, I haven't checked in that sort of detail before. So we may have more than one problem here, but it still looks to me that p16 is not being set up properly. What do you think, Joao? BTW, I don't care how test_octave.sh is modified so long as the result always works and it is not some gross workaround to a known problem that can be fixed in an easier way. I will try the patch (or Joao's modification of it) to test_octave.sh after Joao and you have had a chance to react on the simple test and Joao has had a chance to react to my concern that p16 is not being set up the same as the other p examples. 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-04-16 15:32:42
|
On Wednesday 16 April 2003 16:13, Alan W. Irwin wrote: | On Wed, 16 Apr 2003, Rafael Laboissiere wrote: | > * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]: | So we may have more than one problem here, but it still looks to me | that p16 is not being set up properly. What do you think, Joao? It might be a bug. My priorities at the moment are: 1-add "-drvopt defvis" to xwin 2-make the surface plots z axis aware ( I had no feedback on this) 3-install the XP package on my computer (XP is from M$ :) 4-look at p16. The reason why I put 1 and 2 first is that I know exactly what to do. 3 has to be done ASAP. 4 *might* be a bug and to check/fix it might take more time. Joao | | BTW, I don't care how test_octave.sh is modified so long as the | result always works and it is not some gross workaround to a known | problem that can be fixed in an easier way. I will try the patch (or | Joao's modification of it) to test_octave.sh after Joao and you have | had a chance to react on the simple test and Joao has had a chance to | react to my concern that p16 is not being set up the same as the | other p examples. | | 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 affiliation with the PLplot scientific plotting software | package (plplot.org). | | __________________________ | | Linux-powered Science | __________________________ | | | | ------------------------------------------------------- | 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: Alan W. I. <ir...@be...> - 2003-04-16 17:36:13
|
On Wed, 16 Apr 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > On Wednesday 16 April 2003 16:13, Alan W. Irwin wrote: > | On Wed, 16 Apr 2003, Rafael Laboissiere wrote: > | > * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]: > > | So we may have more than one problem here, but it still looks to me > | that p16 is not being set up properly. What do you think, Joao? > > It might be a bug. > > My priorities at the moment are: > 1-add "-drvopt defvis" to xwin Just saw that in cvs. Thanks! I also hope you have time to follow up with Sebastian Kuzminsky's X problem. Sounded like you were close to finding th= e X server conditions where xwin did not work (but tk and ntk do work), and h= e seemed very cooperative about running tests to find out the source of this strange problem. > 2-make the surface plots z axis aware ( I had no feedback on this) There are no hard and fast rules about the appropriate time for making this fix. You are closest to the extent of the changes you have to make, and it is your judgement call balancing the benefits of a fix with the chances of introducing another bug. Presumably, you will have thoroughly tested your fix under Linux and OSF1. Under those conditions I would be all for making the fix unless it introduces complications such as new API, new system libraries, new headers, etc. which might introduce cross-platform issues on platforms other than Linux and OSF1. > 3-install the XP package on my computer (XP is from M$ :) XP sounds like a black hole that will suck you in forever....;-) > 4-look at p16. With regard to (4) I just tried Rafael's patch, and I confirm it is really slow with an interactive GUI popping on and off the screen for every p example (as opposed to just the first one before). So it gives a bad impression, but at least it doesn't crash, and it appears there are no overwrites of previous files by p16 (presumably because of Rafael's reinitialization before p16 is run). Clearly, Joao has run out of time (as have I because there is a full announcement I have to write for the release as well as my other work) so the final decision is really up to Rafael. I do ask Rafael to have a quick look at p16 to see if there is any obvious familying initialization problem= =2E I don't know octave well enough to trace this back to the equivalent PLplot function calls, but at a low level, pladv has to be invoked in exactly the right order as in my recent x21c.c fix for familying to work properly. Perhaps comparison with the initialization in p7 and p15 (both of which hav= e no familying problems) will help sort this out. If Rafael cannot find anything or has run out of time to deal with this bug, I would be willing t= o go along with the patch on a temporary basis to work around it just for thi= s release. Regardless of Rafael's decision for this p16 problem, I also would like som= e resolution to the no-familying bug he found on his home machine yesterday. Also we need some input from Geoffrey (now that Maurice is gone on vacation) about the status of tcl/tk wish and tclsh plplot support on solaris (and the Linux distributions he has access to). 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 affiliation with the PLplot scientific plotting software packag= e (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-04-16 17:54:25
|
* Alan W. Irwin <ir...@be...> [2003-04-16 10:35]: > Clearly, Joao has run out of time (as have I because there is a full > announcement I have to write for the release as well as my other work) so > the final decision is really up to Rafael. I do ask Rafael to have a quick > look at p16 to see if there is any obvious familying initialization > problem. I don't know octave well enough to trace this back to the > equivalent PLplot function calls, but at a low level, pladv has to be > invoked in exactly the right order as in my recent x21c.c fix for familying > to work properly. Perhaps comparison with the initialization in p7 and p15 > (both of which have no familying problems) will help sort this out. If > Rafael cannot find anything or has run out of time to deal with this bug, I > would be willing to go along with the patch on a temporary basis to work > around it just for this release. I have no time to look at p16.m right now and I doubt that I will do during the next week. Doing this means code analysis and it will take much more time than the mechanical work of tarball generation or even the fixing of obvious bugs. I would vote for the patch for now. As regards the plans for the release, it seems that we are already behind schedule. What about delaying the announcement of one week, but releasing RC2 this coming weekend? > Regardless of Rafael's decision for this p16 problem, I also would like some > resolution to the no-familying bug he found on his home machine yesterday. Let us forget that. I erased many things that I did yesterday and my machine at home is running Debian unstable, so its system is changing on a day-to-day basis. > Also we need some input from Geoffrey (now that Maurice is gone on > vacation) about the status of tcl/tk wish and tclsh plplot support on > solaris (and the Linux distributions he has access to). If your LIBRARY_VERSION hack works for Linux and Soalris, at least, let us keep it for now. I may find a solution in the future to adjust pkgIndex.tcl using the information available in libplplot.la. I think that it is a bad idea delaying the release for that. Of course, we should add a note in the announcement about this problem. Someone already said "release often, release early", and we should adopt this motto. -- Rafael |
From: Alan W. I. <ir...@be...> - 2003-04-16 22:22:28
|
On Wed, 16 Apr 2003, Rafael Laboissiere wrote: > I have no time to look at p16.m right now and I doubt that I will do during > the next week. Doing this means code analysis and it will take much more > time than the mechanical work of tarball generation or even the fixing of > obvious bugs. > > I would vote for the patch for now. I will go along with whatever you and Joao decide. You have now both confirmed the bug, and last I heard it sounded like he was on a promising trail (finding a similar problem for another example), but if that doesn't pan out, the patch is an ugly but acceptable solution for a temporary release-only workaround. > > Regardless of Rafael's decision for this p16 problem, I also would like some > > resolution to the no-familying bug he found on his home machine yesterday. > > Let us forget that. I erased many things that I did yesterday and my > machine at home is running Debian unstable, so its system is changing on a > day-to-day basis. That's fine if everything works again there, but not so good if familying continues not to work. If the problem persists you should be quickly able to see whether it is a bash bug or script bug that is preventing the exported options variable to be passed to test_octave.sh. If that variable is getting through okay, then there may be a problem with plsetopt for Debian unstable, but that is also easy to test and either note the limitation to be documented for the release or fix it. > > > Also we need some input from Geoffrey (now that Maurice is gone on > > vacation) about the status of tcl/tk wish and tclsh plplot support on > > solaris (and the Linux distributions he has access to). > > If your LIBRARY_VERSION hack works for Linux and Soalris, at least, let us > keep it for now. I may find a solution in the future to adjust pkgIndex.tcl > using the information available in libplplot.la. I think that it is a bad > idea delaying the release for that. Of course, we should add a note in the > announcement about this problem. > > Someone already said "release often, release early", and we should adopt > this motto. I absolutely agree. If we know we are going to release often (say once per quarter), then I think everybody will not worry so much about release deadlines and just relax and do their best work. > > [out of order] As regards the plans for the release, it seems that we are already behind > schedule. What about delaying the announcement of one week, but releasing > RC2 this coming weekend? I think it is better for all of us not to delay the release by more than a day or two at most, and I still think there is an excellent chance to get it out this Saturday on time. Since this deadline has been known long in advance, I planned my life accordingly and next weekend after this is not particularly good for me, and I imagine it is the same story for most of the rest of us. Also, if something doesn't get done in time for release all we have to do is be clear in the announcement or associated documentation about any limitations there may be. The octave decisions are under Joao's and your control. I think for both sets of problems there you are in a position for a fix, a workaround or simply noting the limitation. So I don't think those issues should delay the release from this weekend. The only really big uncertainty at the moment is solaris. Apparently some time ago the big December AT change was tested (at least partially) by Maurice for solaris, but that doesn't say much about the current status. What is the solaris testing story, Geoffrey? Please make as good an estimate as possible about whether you or Maurice (when he is back from vacation) are likely in the near future to spend the hour or so required for a straightforward functionality test (plplot-test.sh and all the interactive tests mentioned in README.tcldemos and README.tkdemos). Even if a part of it doesn't work, we don't have to get involved in fixing it unless it is something really simple. All we really have to do is make sure the solaris limitations (if any) are documented 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Joao C. <jc...@fe...> - 2003-04-16 23:57:05
|
On Wednesday 16 April 2003 23:21, Alan W. Irwin wrote: | On Wed, 16 Apr 2003, Rafael Laboissiere wrote: | > I have no time to look at p16.m right now and I doubt that I will do | > during the next week. Doing this means code analysis and it will take | > much more time than the mechanical work of tarball generation or even | > the fixing of obvious bugs. | > | > I would vote for the patch for now. | | I will go along with whatever you and Joao decide. You have now both | confirmed the bug, and last I heard it sounded like he was on a promising | trail (finding a similar problem for another example), but if that doesn't | pan out, the patch is an ugly but acceptable solution for a temporary | release-only workaround. After burning the CD and installing the XP package(*), I have changed octave plsetop(). With this change the problem seems to be solved, but please check it. | Also, if something doesn't get done in time for release all | we have to do is be clear in the announcement or associated documentation | about any limitations there may be. Agree. Joao (*) The XP package is fantastic! It emulates a real OS in almost all details! |
From: Alan W. I. <ir...@be...> - 2003-04-17 01:40:42
|
On Thu, 17 Apr 2003, Joao Cardoso wrote: > [...] I have changed octave > plsetop(). With this change the problem seems to be solved, but please check > it. From fresh cvs checkout, build and install went fine. plplot-test.sh showed example 11 had cmap1 out of range errors for many front ends. I fixed that following what you did for x11c.c (see latest commit). After a reinstall of those changed examples, plplot-test.sh built all psc and png plots without any obvious problems. The dead GUI is now gone as well for the octave part of the test. It is great to have plplot-test.sh working again. Thanks! > (*) The XP package is fantastic! It emulates a real OS in almost all details! My original "black-hole" joke was because I believed you were installing Windows XP. But "XP package" sounds possibly different from that. If so, got a URL? 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-04-17 15:45:35
|
On Thursday 17 April 2003 02:39, Alan W. Irwin wrote: | On Thu, 17 Apr 2003, Joao Cardoso wrote: | > [...] I have changed octave ... | > (*) The XP package is fantastic! It emulates a real OS in almost | > all details! | | My original "black-hole" joke was because I believed you were | installing Windows XP. But "XP package" sounds possibly different | from that. If so, got a URL? Sure, www.microsoft.com. And it's not a black-hole, that end is too glorious, it's a brown dwarf :) Joao | | 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 affiliation with the PLplot scientific plotting software | package (plplot.org). | | __________________________ | | Linux-powered Science | __________________________ |
From: Geoffrey F. <fu...@li...> - 2003-04-17 01:28:59
|
Alan W. Irwin writes: > > > Also we need some input from Geoffrey (now that Maurice is gone on > > > vacation) about the status of tcl/tk wish and tclsh plplot support on > > > solaris (and the Linux distributions he has access to). > > > > If your LIBRARY_VERSION hack works for Linux and Soalris, at least, let us > > keep it for now. I may find a solution in the future to adjust pkgIndex.tcl > > using the information available in libplplot.la. I think that it is a bad > > idea delaying the release for that. Of course, we should add a note in the > > announcement about this problem. > > > > Someone already said "release often, release early", and we should adopt > > this motto. > > I absolutely agree. If we know we are going to release often (say once per > quarter), then I think everybody will not worry so much about release > deadlines and just relax and do their best work. > [...] > The only really big uncertainty at the moment is solaris. Apparently some > time ago the big December AT change was tested (at least partially) by > Maurice for solaris, but that doesn't say much about the current status. > > What is the solaris testing story, Geoffrey? Please make as good an > estimate as possible about whether you or Maurice (when he is back from > vacation) are likely in the near future to spend the hour or so required for > a straightforward functionality test (plplot-test.sh and all the interactive > tests mentioned in README.tcldemos and README.tkdemos). Even if a part of it > doesn't work, we don't have to get involved in fixing it unless it is > something really simple. All we really have to do is make sure the solaris > limitations (if any) are documented for the release. Maurice won't be back in the loop till Monday. I'm off starting Friday am for a long weekend too. Tomorrow I have just about a half day. I'll see if I can fit in a Solaris eval tomorrow afternoon, but honestly, it's a long shot. There is a real possibility that you won't get anything meaningful out of either of us until next week. -- Geoffrey Furnish Lightspeed Semiconductor Corp voice: 512-402-9016 11612 Bee Cave Road, Suite 130 fax: 512-402-9643 Austin, Texas 78738 |
From: Alan W. I. <ir...@be...> - 2003-04-17 02:16:38
|
On Wed, 16 Apr 2003, Geoffrey Furnish wrote: > Maurice won't be back in the loop till Monday. I'm off starting Friday am > for a long weekend too. Tomorrow I have just about a half day. I'll see if > I can fit in a Solaris eval tomorrow afternoon, but honestly, it's a long > shot. There is a real possibility that you won't get anything meaningful out > of either of us until next week. OK. I would appreciate you doing what you can tomorrow (Thursday), and I will be happy to help out (by phone or e-mail) if you run into any problem getting started with it since I believe it has been a while since you built PLplot with the new paradigm. Rafael, could you make a tarball from current CVS for Geoffrey to use? My vote is regardless of how this turns out we release on Saturday. If Geoffrey can give us the solaris status that would be wonderful, but if not, I will just say that solaris remains untested. Rafael, if you agree to a Saturday release, then I will need you to do everything you did last weekend to prepare the tarball, and I will do the rest. BTW, for those of you wondering how much public testing we have gotten, there have been 64 downloads of plplot-5.2.1.rc1.tar.gz from SF in the first two days after the release. (SF statistics are two-days old so I don't have any later information than that.) Thus, the early indications are it has been a reasonable (and from the two excellent user reports we got definitely useful) testing response, but not the large testing response I was hoping for. So just like the previous releases, we are pretty much relying on our own testing to determine the quality of this 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <lab...@ps...> - 2003-04-17 07:25:46
|
* Alan W. Irwin <ir...@be...> [2003-04-16 19:15]: > Rafael, could you make a tarball from current CVS for Geoffrey to use? Done and uploaded to http://people.debian.org/~rafael/plplot.html Its md5sum is 524977e5f0c71d825617d350e4b71de8 -- Rafael |
From: <jc...@fe...> - 2003-04-16 18:33:06
|
On Wednesday 16 April 2003 18:35, Alan W. Irwin wrote: | On Wed, 16 Apr 2003, [iso-8859-1] Jo=E3o Cardoso wrote: | > On Wednesday 16 April 2003 16:13, Alan W. Irwin wrote: | > | On Wed, 16 Apr 2003, Rafael Laboissiere wrote: | > | > * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]: =2E.. | > 2-make the surface plots z axis aware ( I had no feedback on this) | | There are no hard and fast rules about the appropriate time for | making this fix. You are closest to the extent of the changes you | have to make, and it is your judgement call balancing the benefits of | a fix with the chances of introducing another bug. Presumably, you | will have thoroughly tested your fix under Linux and OSF1. Under | those conditions I would be all for making the fix unless it | introduces complications such as new API, new system libraries, new | headers, etc. which might introduce cross-platform issues on | platforms other than Linux and OSF1. Just a couple of code line changes. Done. =2E.. | > 4-look at p16. | | With regard to (4) I just tried Rafael's patch, and I confirm it is | really slow with an interactive GUI popping on and off the screen for | every p example (as opposed to just the first one before). Do you remember if this happened before? I find it odd. I recently made=20 octave plsetop() to open an window if none is already opened, but for=20 this test it is ugly. | So it | gives a bad impression, but at least it doesn't crash, and it appears | there are no overwrites of previous files by p16 (presumably because | of Rafael's reinitialization before p16 is run). At the office computer I can also reproduce the bug. But... changing=20 test_octave.sh such that the only tests are p15, p16 and adding p21,=20 gives the following: Opened p15.png.01 Opened p15.png.02 Opened p16.png.01 Opened p21.png.01 *** PLPLOT WARNING *** plsfam: Must be called before plinit. *** PLPLOT WARNING *** plsdev: Must be called before plinit. etc. Thus the problem is not in p16!!! While the XP CD is burning I will=20 take a look. Joao |
From: Alan W. I. <ir...@be...> - 2003-04-16 18:44:17
|
On Wed, 16 Apr 2003, [iso-8859-1] Jo=E3o Cardoso wrote: > | With regard to (4) I just tried Rafael's patch, and I confirm it is > | really slow with an interactive GUI popping on and off the screen for > | every p example (as opposed to just the first one before). > > Do you remember if this happened before? I find it odd. I recently made > octave plsetop() to open an window if none is already opened, but for > this test it is ugly. I don't recall the dead GUI for anything before RC1, but it has been a whil= e since I tested. 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 affiliation with the PLplot scientific plotting software packag= e (plplot.org). __________________________ Linux-powered Science __________________________ |
From: <jc...@fe...> - 2003-04-16 15:16:19
|
On Wednesday 16 April 2003 08:51, Rafael Laboissiere wrote: | * Alan W. Irwin <ir...@be...> [2003-04-15 18:59]: ... | My guess is that text_octave.sh is doing things in the wrong way, by | calling plplot_stub only once and then looping over the p??.m files. | Now, each file needs a different way of being initialized and then | the clash happens in p16.m. Perhaps. | In other words, the bug is in test_octave.sh! | | I propose the patch attached below. The loop is done at the shell | level and octave is called individually for each demo file. It is | much slower, but it works. Joao and Alan: do you agree with the | patch? If it works, go ahead! Latter I *should* see what is p16 triggering (or is it the *previous* demo?), and correct it. Joao |
From: Joao C. <jc...@fe...> - 2003-04-16 03:03:33
|
On Tuesday 15 April 2003 22:03, Alan W. Irwin wrote: ... | *** There was one nasty RC1 failure for the combination of octave and png | device. | | Opened p16.png.01 | | *** PLPLOT WARNING *** | plsfam: Must be called before plinit. | | *** PLPLOT WARNING *** | plsdev: Must be called before plinit. | Plplot library version: 5.2.1.rc1 | | followed by a whole bunch of garbage output. The problem you report happened with me once. I couldn't reproduce it afterwards. If you do: octave:1> figure(1,"png","po.png"); Opened po.png octave:2> p16 octave:3> closefig everything is OK. That is exactly what test_octave.sh does. Thus the problem must be somewhere else, either in test_octave.sh or plplot-test.sh, but I can't find where (and the other examples work fine). The above test was done with octave-2.1.36, running octave in bindings/octave, and as a regular user, with the installed plplot, setting first LOADPATH="/usr/local/test/share/plplot_octave//:/usr/local/test/lib/plplot5.2.1.rc1/examples/octave//:" | Warnings. | | I did notice some warnings along the way. configure still outputs the | following: | | configure: WARNING: itclDecls.h: present but cannot be compiled | configure: WARNING: itclDecls.h: check for missing prerequisite headers? | configure: WARNING: itclDecls.h: proceeding with the preprocessor's result | configure: WARNING: ## ------------------------------------ ## | configure: WARNING: ## Report this to bug...@gn.... ## | configure: WARNING: ## ------------------------------------ ## Interestingly this WARNING does not occurs with RH-8.0. But occurs with suse-8.1. Since I can remember. | * /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.35 | -I/usr/include/octave-2.1.35/ | octave -I/usr/include -mieee-fp -fno-implicit-templates -O2 -I. | plplot_octave.cc | -o plplot_octave.o | In file included from /usr/include/octave-2.1.35/octave/oct.h:31, | from plplot_octave.cc:11: | /usr/include/octave-2.1.35/octave/config.h:148: warning: | HAVE_ISINF' redefined | ../../config.h:36: warning: this is the location of the previous | definition /usr/include/octave-2.1.35/octave/config.h:151: warning: | HAVE_ISNAN' redefined ../../config.h:39: warning: this is the location of | the previous definition /usr/include/octave-2.1.35/octave/config.h:288: | warning: HAVE_FINITE' redefined | ../../config.h:24: warning: this is the location of the previous | definition /usr/include/octave-2.1.35/octave/config.h:474: warning: | HAVE_USLEEP' redefined | ../../config.h:101: warning: this is the location of the previous | definition I had already reported this one, and said that it was unavoidable and harmless. Octave configure.h, that is used when compiling any user octave function, also defines HAVE_ISINF etc, and thus the clash. Joao |
From: Alan W. I. <ir...@be...> - 2003-04-16 04:39:03
|
On Wed, 16 Apr 2003, Joao Cardoso wrote: > On Tuesday 15 April 2003 22:03, Alan W. Irwin wrote: > ... > > | *** There was one nasty RC1 failure for the combination of octave and png > | device. > | > | Opened p16.png.01 > | > | *** PLPLOT WARNING *** > | plsfam: Must be called before plinit. > | > | *** PLPLOT WARNING *** > | plsdev: Must be called before plinit. > | Plplot library version: 5.2.1.rc1 > | > | followed by a whole bunch of garbage output. > > The problem you report happened with me once. I couldn't reproduce it > afterwards. > > If you do: > > octave:1> figure(1,"png","po.png"); > Opened po.png > octave:2> p16 > octave:3> closefig > > everything is OK. That is exactly what test_octave.sh does. I can reproduce the above with no errors and po.png seems to display okay with kview. However, that simple test ignores the familying option that is imposed via $options in test_octave.sh, and also doesn't try any other plots first. If I modify the above test for familying and trying other plots first a bug results for p16 on my system but not for any other case. Specifically, to reproduce the bug I must do the following: octave -p "/usr/local/plplot_at/share/plplot_octave//:/usr/local/plplot_at/lib/plplot5.2.1.rc1/examples/octave//:" GNU Octave, version 2.1.35 (i386-pc-linux-gnu). Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 John W. Eaton. This is free software with ABSOLUTELY NO WARRANTY. For details, type warranty'. *** This is a development version of Octave. Development releases *** are provided for people who want to help test, debug, and improve *** Octave. *** *** If you want a stable, well-tested version of Octave, you should be *** using one of the stable releases (when this development release *** was made, the latest stable version was 2.0.16). octave:1> plsetopt("fam", "yes") warning: It is recommended that you set 'automatic_replot=1' in your ~/.octaverc file. warning: in /usr/local/plplot_at/share/plplot_octave/figure.m near line 59, column 7: >>> warning ("It is recommended that you set 'automatic_replot=1' \n\t in your ~/.octaverc file."); ans = octave:2> figure(1,"png","po.png"); Opened po.png.1 octave:3> p1 octave:4> p7 Opened po.png.2 Opened po.png.3 octave:5> p16 octave:6> p16 octave:7> p7 Opened po.png.4 Opened po.png.5 octave:8> p1 Opened po.png.6 Notice, that p7 produces two pages every time, and p1 produces one page, but p16 (with no error message in this case) produces no pages in familying mode. If I do p16 alone after plsetopt and figure, a good result is produced. Joao, from your other good script results you probably won't be able to reproduce this bug on your system, but could you double check please using exactly the above octave commands in the order given? Note I am using octave 2.1.35. Also, I suspect my above plsetopt call is a little clumsy (I am not sure whether the "yes" is necessary), but it seems to get the job done for p7 (and p16 if done alone). Rafael, please try the same test. (I am scared to predict the outcome except that it will probably be different from both Joao's results and mine....;-)) 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 affiliation with the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |