From: Alan W. I. <ir...@be...> - 2010-02-25 21:47:36
|
Here is the result for the CMake-based build system for the installed examples: software@raven> c/x01c -dev tk PLplot library version: 5.9.5 TCL command "plclient_init" failed: invalid command name "plclient_init" TCL command "plclient_link_end" failed: invalid command name "plclient_link_end" Program aborted examples/c/x01c -dev tk works fine in the build tree. This error message is identical to one I was getting before (both build and install tree) for the embedded blank case and which was supposed to be fixed by the combination of Arjen and Andrew's efforts. The current issue is for the case where there are no embedded blanks. I am not sure whether it is a regression caused by the embedded blank fix or a regression caused by a previous -dev tk fix, but -dev tk (as run by the test_interactive target) used to work fine for the CMake-based build system for the installed examples. I discovered this issue by routine testing using the test_interactive target for both the build tree and install tree and I recommend doing both those tests (or a subset such as test_c_tk, use "make help |grep test" to see the full list of test targets) for all others here as well whenever a change has been made to an interactive device such as -dev tk. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David M. <da...@as...> - 2010-02-25 22:04:55
|
Hi, Alan, On Feb 25, 2010, at 13:47 , Alan W. Irwin wrote: > I am > not sure whether it is a regression caused by the embedded blank > fix or a > regression caused by a previous -dev tk fix, but -dev tk (as run by > the > test_interactive target) used to work fine for the CMake-based > build system > for the installed examples. I can't help you with the tk problem, but wanted to note that this kind of situation is exactly why "git bisect" was created: finding the exact commit that breaks something. You start off by giving "git bisect" the last known good version and the currently known bad version and it checks out a version "in the middle". You build/test that version, tell "git bisect" whether it is good or bad, and it then checks out a version "in the middle" of the updated known-good/ known-bad range. The process repeats until the exact change which introduces the problem is identified. If you can automate/script the build/test steps, then git can iterate to the end without any intervention! Sorry for the off-topic advocacy, Dave |
From: Alan W. I. <ir...@be...> - 2010-02-25 23:13:46
|
On 2010-02-25 14:04-0800 David MacMahon wrote: > Hi, Alan, > > On Feb 25, 2010, at 13:47 , Alan W. Irwin wrote: > >> I am >> not sure whether it is a regression caused by the embedded blank fix or a >> regression caused by a previous -dev tk fix, but -dev tk (as run by the >> test_interactive target) used to work fine for the CMake-based build system >> for the installed examples. > > I can't help you with the tk problem, but wanted to note that this kind of > situation is exactly why "git bisect" was created: finding the exact commit > that breaks something. You start off by giving "git bisect" the last known > good version and the currently known bad version and it checks out a version > "in the middle". You build/test that version, tell "git bisect" whether it > is good or bad, and it then checks out a version "in the middle" of the > updated known-good/known-bad range. The process repeats until the exact > change which introduces the problem is identified. If you can > automate/script the build/test steps, then git can iterate to the end without > any intervention! > > Sorry for the off-topic advocacy, Want to give git-bisect a try for this case? If so, here are the instructions for reproducing the error. I am pretty sure that you use Mac OS X? If so, my understanding is it is fairly straightforward to get X and Tcl/Tk installed on that platform. Once that is completed, the rest of the test is simple to set up. Use the following cmake options -DDEFAULT_NO_BINDINGS=ON -DENABLE_tcl=ON -DENABLE_tk=ON -DDEFAULT_NO_DEVICES=ON -DPLD_tk=ON to tremendously speed up builds by dropping everything other than the absolute essentials to build and test -dev tk. In empty build tree: cmake ... options including -DCMAKE_INSTALL_PREFIX make install In _new_ empty build tree for build of examples that were installed by the previous command. cmake $install_prefix/share/plplot5.9.5/examples >& cmake.out make test_c_tk (Currently shows error). I hope you do respond to this challenge for two reasons: (1) to show off git capabilities and (2) to give us some practical help here. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-02-26 17:27:46
|
On 2010-02-25 15:13-0800 Alan W. Irwin wrote: > Want to give git-bisect a try for this case? If so, here are the > instructions for reproducing the error. All good ideas are copied. From a google search for svn bisect, it appears there is now a perl svn-bisect script to do svn bisect plus an "official" svn-bisect script in the works. I plan to try the perl script for now to see how fast I can come up with the answer for which revision caused this regression. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David M. <da...@as...> - 2010-02-26 18:35:43
|
On Feb 26, 2010, at 9:27 , Alan W. Irwin wrote: > On 2010-02-25 15:13-0800 Alan W. Irwin wrote: > >> Want to give git-bisect a try for this case? If so, here are the >> instructions for reproducing the error. > > All good ideas are copied. From a google search for svn bisect, it > appears > there is now a perl svn-bisect script to do svn bisect plus an > "official" > svn-bisect script in the works. > > I plan to try the perl script for now to see how fast I can come up > with the answer for which revision caused this regression. Great! I'll try it with git, but I'm not sure how soon I'll be able to get to it. Dave |
From: Alan W. I. <ir...@be...> - 2010-02-26 19:19:28
Attachments:
AWIREADME
|
On 2010-02-26 09:27-0800 Alan W. Irwin wrote: > All good ideas are copied. From a google search for svn bisect, it appears > there is now a perl svn-bisect script to do svn bisect plus an "official" > svn-bisect script in the works. > > I plan to try the perl script for now to see how fast I can come up > with the answer for which revision caused this regression. It was something of a struggle to install the App::SVN::Bisect perl module because of dependencies. I have attached my (extremely Debian-specific) notes on how to deal with those dependency issues. These notes should be useful for those here running Debian or a Debian derivative such as Ubuntu. The next steps are (1) Update my local svn repository for PLplot. Normally I update that every few months as a sometimes backup of the SF repo while Maurice does that on a daily basis as part of an automatic backup script he is running. In this case I will be using the local repository to greatly improve speed as the bisect updates to a variety of different revisions. (2) Write a script to do the steps mentioned in the previous e-mail to demonstrate the error. This is straightforward, but it needs to be done for every error where either git-bisect or svn-bisect is to be used to find the revision that corresponds to introducing the regression. (3) Check out PLplot from the local repository, set up the svn-bisect range with svn-bisect --min good-revision --max bad-revision start then run svn-bisect run testscript.sh to find the bad revision, and svn-bisect reset to restore the local version back to normal. This all seems straightforward, but we will see! Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David M. <da...@as...> - 2010-02-26 19:29:21
|
On Feb 26, 2010, at 11:19 , Alan W. Irwin wrote: > (1) Update my local svn repository for PLplot. I can't resist pointing out that git always has a local repository! It can't really be called a local copy of *the* repository, but it is local. :-) > (2) Write a script to do the steps mentioned in the previous e-mail to > demonstrate the error. This is straightforward, but it needs to be > done for every error where either git-bisect or svn-bisect is to be > used > to find the revision that corresponds to introducing the regression. With this script, it should be very easy for me to run "git bisect". It will also make it easier for me to fit in that task time-wise! :-) Dave |
From: Alan W. I. <ir...@be...> - 2010-02-26 21:34:22
|
On 2010-02-26 11:29-0800 David MacMahon wrote: > > On Feb 26, 2010, at 11:19 , Alan W. Irwin wrote: > >> (1) Update my local svn repository for PLplot. > > I can't resist pointing out that git always has a local repository! It can't > really be called a local copy of *the* repository, but it is local. :-) > >> (2) Write a script to do the steps mentioned in the previous e-mail to >> demonstrate the error. This is straightforward, but it needs to be >> done for every error where either git-bisect or svn-bisect is to be used >> to find the revision that corresponds to introducing the regression. > > With this script, it should be very easy for me to run "git bisect". It will > also make it easier for me to fit in that task time-wise! :-) I am done. The bad revision is 10794 (Andrew, the one where you fixed up issues with embedded blanks in directory names according to Arjen's suggestions.) revision 10793 works fine. Andrew, could you take a look please? The rest of this is about the method of finding that first bad revision. Bisection is a clear winner here (whether done with git-bisect or svn-bisect) to find the source of regressions. The script I used for this purpose was scripts/test_bisect.sh (revision 10819). Obviously (since that script is under version control), you must copy that script elsewhere when looking for a revision that executes the script without problems. There is some art to finding a good revision. For example, in the present case the result of that rough search was revision 10775 as a "good" revision while you cannot go back too far from that revision before you run into other -dev tk issues that were solved somewhere between 10750 and 10775. Once I determined that revision 10775 was good, then svn-bisect --min 10775 --max 10819 start svn-bisect run $OTHER_DIR/test_bisect.sh ==> revision 10794 was the bad one. The whole svn-bisect approach only took a few minutes. I think it would have been a lot longer if I was using the SF repo (see below about how to create and use a local repo). Clean up afterwards with svn-bisect revert svn update For those who don't know this, here is how to create (or update in my case) a local PLplot repo. rsync -av --delete \ plplot.svn.sourceforge.net::svn/plplot/* plplot This created /home/software/plplot_svn/svn_backup/plplot in my case. To use that repo I executed svn checkout file:///home/software/plplot_svn/svn_backup/plplot/trunk \ plplot_bisect Subsequently, all my bisection work was done in the plplot_bisect directory which made svn updates very fast. Note, svn update is used initially (and manually) a lot to find a good revision. svn-bisect also uses svn update a modest amount. The number of updates goes as the log base 2 of the revision range. Thus, a range of 1024 revisions only requires 10 updates to find which revision fails by bisection. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David M. <da...@as...> - 2010-02-26 21:46:58
|
Nice work, Alan! Bisection is clearly useful regardless of the tool used to drive it! On Feb 26, 2010, at 13:34 , Alan W. Irwin wrote: > Thus, a range of 1024 revisions only requires 10 updates to find > which revision fails by bisection. Just to be explicit, it's not just (only!) 10 updates, it's (only!) 10 update/build/test iterations to identify the first "bad" revision within a range of 1024 revisions. The same bisection technique could be done manually, but it's very tedious (and "Murphy prone"! :-)). Dave |
From: Andrew R. <and...@us...> - 2010-02-27 14:34:47
|
On Fri, Feb 26, 2010 at 01:34:15PM -0800, Alan Irwin wrote: > On 2010-02-26 11:29-0800 David MacMahon wrote: > > > > > On Feb 26, 2010, at 11:19 , Alan W. Irwin wrote: > > > >> (1) Update my local svn repository for PLplot. > > > > I can't resist pointing out that git always has a local repository! It can't > > really be called a local copy of *the* repository, but it is local. :-) > > > >> (2) Write a script to do the steps mentioned in the previous e-mail to > >> demonstrate the error. This is straightforward, but it needs to be > >> done for every error where either git-bisect or svn-bisect is to be used > >> to find the revision that corresponds to introducing the regression. > > > > With this script, it should be very easy for me to run "git bisect". It will > > also make it easier for me to fit in that task time-wise! :-) > > I am done. The bad revision is 10794 (Andrew, the one where you > fixed up issues with embedded blanks in directory names according to > Arjen's suggestions.) revision 10793 works fine. Andrew, could you take > a look please? I'll try and take a look unless Arjen beats me to it. Andrew |
From: Andrew R. <and...@us...> - 2010-03-01 20:19:21
|
On Sat, Feb 27, 2010 at 02:34:34PM +0000, Andrew Ross wrote: > On Fri, Feb 26, 2010 at 01:34:15PM -0800, Alan Irwin wrote: > > On 2010-02-26 11:29-0800 David MacMahon wrote: > > > > > > > > On Feb 26, 2010, at 11:19 , Alan W. Irwin wrote: > > > > > >> (1) Update my local svn repository for PLplot. > > > > > > I can't resist pointing out that git always has a local repository! It can't > > > really be called a local copy of *the* repository, but it is local. :-) > > > > > >> (2) Write a script to do the steps mentioned in the previous e-mail to > > >> demonstrate the error. This is straightforward, but it needs to be > > >> done for every error where either git-bisect or svn-bisect is to be used > > >> to find the revision that corresponds to introducing the regression. > > > > > > With this script, it should be very easy for me to run "git bisect". It will > > > also make it easier for me to fit in that task time-wise! :-) > > > > I am done. The bad revision is 10794 (Andrew, the one where you > > fixed up issues with embedded blanks in directory names according to > > Arjen's suggestions.) revision 10793 works fine. Andrew, could you take > > a look please? > > I'll try and take a look unless Arjen beats me to it. The revision is question was quite small so it didn't take long to find the problem. Turned out to be an issue with the list handling of the tcl auto_path variable. Revision 10836 fixes the problem. I've also checked that directory names with blanks still work (and they do). Regards Andrew |
From: Arjen M. <arj...@de...> - 2010-03-02 07:37:11
|
Hi Andrew, ah, you found it! Good to hear that. (The original code made a list of two elements, one of them being a list in itself.) Regards, Arjen > > The revision is question was quite small so it didn't take long to find > the problem. Turned out to be an issue with the list handling of the tcl > auto_path variable. Revision 10836 fixes the problem. I've also checked > that directory names with blanks still work (and they do). > |