Menu
▾
▴
gnuplot-beta
|
From: Thomas M. <mat...@ph...> - 2006-03-01 22:16:14
|
Hi
I have made a bunch of improvements to gnuplot fitting.
They are in src/fit.c, plus some changes to demo/fit.dem.
They are described in a separate message.
How do I commit the changes? I started by CVS downloading
gnuplot 4.1, made my changes, and have done a CVS update since
making my changes, so I should be in synch with everyone else.
But when I tried to CVS commit, I got a broken pipe abort.
I'm working on a Linux system.
I have also made some new short demo files to demonstrate
the reason for and effect of the improvements. These would
be new files, and they are really for developers rather than
users. How should they be handled?
Finally, the documentation should be changed to reflect the
changes in fitting. What is the proper way to edit the source
for documentation, and to test the changes?
Cheers
Prof. Thomas Mattison, Dept. of Physics & Astronomy, Univ. of British
Columbia
Present Address: Stanford Linear Accelerator Center
2575 Sand Hill Road, Menlo Park, CA, 94025
Building 48 (Research Office Building), Mail Station MS35
Office: ROB-231 Phone: 650-926-5342 Fax: 650-926-8522
|
|
From: Lars H. <lhe...@us...> - 2006-03-02 10:31:27
|
> How do I commit the changes? I started by CVS downloading Use the patch tracker on SF. > gnuplot 4.1, made my changes, and have done a CVS update since > making my changes, so I should be in synch with everyone else. > > But when I tried to CVS commit, I got a broken pipe abort. > I'm working on a Linux system. You are not registered as a gnuplot developer on SF, so you have no write access to CVS. This status is awarded on a merit basis - the quality of your contributions to gnuplot development e.g. in the form of code and mailing list discussions. As you have only appeared on our radar last December and posted 4 msgs here in total (including today's), this might not happen just yet :) |
|
From: Thomas M. <mat...@ph...> - 2006-03-02 17:51:47
|
Lars Hecking <lhecking <at> users.sourceforge.net> writes: > > How do I commit the changes? > > Use the patch tracker on SF. OK. Exactly what format of diff-ing should I use, and against what, to create the patch? A cvs diff against the head? A diff against 4.0? What options on the diff command? Also, there are some new test scripts and test data files to demonstrate cases where the existing fits do the wrong thing, and that the changes make it do the right thing. How should that be handled? It appears that the patch submission page on sourceforge expects only one file per patch. Should I tar together the diff output and the new test scripts and data files? Or make multiple "patches"? > > You are not registered as a gnuplot developer on SF, so you have no > write access to CVS. Fair enough. > This status is awarded on a merit basis - the > quality of your contributions to gnuplot development e.g. in the form > of code and mailing list discussions. As you have only appeared on > our radar last December and posted 4 msgs here in total (including > today's), this might not happen just yet :) I read the discussions, but since I'm generally happy with the way gnuplot plots data, and don't claim that my opinions have more weight than others, I haven't weighed in. I'm more interested in improving the fitting part, and there hasn't been discussion of that. |
|
From: Lars H. <lhe...@us...> - 2006-03-02 18:21:52
|
> OK. Exactly what format of diff-ing should I use, and against what, > to create the patch? A cvs diff against the head? A diff against 4.0? > What options on the diff command? > > Also, there are some new test scripts and test data files to demonstrate > cases where the existing fits do the wrong thing, and that the changes make > it do the right thing. How should that be handled? It appears that the patch > submission page on sourceforge expects only one file per patch. Should I > tar together the diff output and the new test scripts and data files? Or make > multiple "patches"? You have two gnuplot directory trees: the original, be it off cvs or 4.0, and your edited tree. Then you just run $ ls gnuplot-x.y.z.orig gnuplot-x.y.z $ diff -ur gnuplot-x.y.z.orig gnuplot-x.y.z >foobar.diff $ gzip/compress/whatever foobar.diff and upload the gzipped diff file. Or, if you made the changes in your checked out copy directly, use "cvs diff -u". But then you need to exclude the CVS directories. The cleanest way is probably: - In the checked-out directory, perform a full build and then "make dist". - Unpack the dist file somewhere else and rename it gnuplot-x.y.z.orig. - Unpack the dist file again in the same directory (gnuplot-x.y.z). This is where you make your edits. The first step is not needed if you start from a distribution archive. The -u option creates a unified diff which is more readable than other diff output formats, and -r recurses through the directory tree (not necessary with cvs diff). This will also include every new file as a patch against a zero-size file. |
|
From: Daniel J S. <dan...@ie...> - 2006-03-02 19:06:09
|
Lars Hecking wrote: > > >>OK. Exactly what format of diff-ing should I use, and against what, >>to create the patch? A cvs diff against the head? A diff against 4.0? >>What options on the diff command? I'd say work against the most recent version in CVS for your own benefit of having the latest of everything and won't have a major update when 4.2 comes out. You'll invariably have hunks rejected at some point that require fixing, so might as well work against the most recent. >> >>Also, there are some new test scripts and test data files to demonstrate >>cases where the existing fits do the wrong thing, and that the changes make >>it do the right thing. How should that be handled? It appears that the patch >>submission page on sourceforge expects only one file per patch. Should I >>tar together the diff output and the new test scripts and data files? Or make >>multiple "patches"? > > > You have two gnuplot directory trees: the original, be it off cvs or > 4.0, and your edited tree. Then you just run > > $ ls > gnuplot-x.y.z.orig gnuplot-x.y.z > $ diff -ur gnuplot-x.y.z.orig gnuplot-x.y.z >foobar.diff > $ gzip/compress/whatever foobar.diff > > and upload the gzipped diff file. > > Or, if you made the changes in your checked out copy directly, use > "cvs diff -u". But then you need to exclude the CVS directories. > > The cleanest way is probably: > > - In the checked-out directory, perform a full build and then "make dist". > - Unpack the dist file somewhere else and rename it gnuplot-x.y.z.orig. > - Unpack the dist file again in the same directory (gnuplot-x.y.z). This > is where you make your edits. I do pretty much the above, but I get a copy from CVS and put it in, say, gnuplot-newfit. Then in the gnuplot-newfit directory where CVS has placed "gnuplot" I > cp -a gnuplot gnuplot-cvs > cp -a gnuplot gnuplot-mod The names are a preference thing, the basic idea is three copies: an untouched CVS version, a source tree modifications only version and a compiled version. In gnuplot-mod is where changes go. In "gnuplot" I will create symbolic links to the files in gnuplot-mod that have been changed. Compile, edit and test everything in "gnuplot". What this does is prevent extraneous and hidden files (from editors) from building up in the "gnuplot-mod" directory. Otherwise bloated files appear in the diff sometimes without paying attention. > diff -ur gnuplot-cvs gnuplot-mod > gnuplot-newfit-ddmmmyyyy.patch e.g., gnuplot-newfit-2mar2006.patch. Also, I'd suggest not leaving in old, commented out text or placing your initials next to changes you've made. That's cruft that will only build up. I don't think people generally do that. (The patch file is often the place to go first for developers so they can see precisely what the changes are; no need for programmer tags.) The time to leave your initials is when there may be some tricky part with a comment, or something that needs to be fixed in the future because of something else in gnuplot that needs to be addressed. Leaving your initials will then help others find the person to ask when it comes time to fix the problem. Oh, yeah, then when it comes to updating your patch against the latest CVS, repeat the "gnuplot/gnuplot-cvs/gnuplot-mod" thing and then from within "gnuplot-mod" do > patch -p1 --dry-run < ../gnuplot-newfit-ddmmmyyyy.patch > patch -p1 < ../gnuplot-newfit-ddmmmyyyy.patch and go about fixing and discarding all the hunk reject files "<file>.rej". Dan |
|
From:
<br...@ph...> - 2006-03-02 19:16:43
|
Lars Hecking wrote:
> Or, if you made the changes in your checked out copy directly, use
> "cvs diff -u". But then you need to exclude the CVS directories.
Not special work on that needed --- 'cvs diff' already excludes those.
> The cleanest way is probably:
>
> - In the checked-out directory, perform a full build and then "make dist".
> - Unpack the dist file somewhere else and rename it gnuplot-x.y.z.orig.
> - Unpack the dist file again in the same directory (gnuplot-x.y.z). This
> is where you make your edits.
If that's what you want, there's an easier way to get it: use "cvs
export" instead of "cvs checkout".
> The -u option creates a unified diff which is more readable than other diff
> output formats, and -r recurses through the directory tree (not necessary
> with cvs diff). This will also include every new file as a patch against a
> zero-size file.
Not quite. It will report all removed and added files as "Only in
{old_dir}" or "Only in {new_dir}". If you want newly created files
spelled out in the diff, you need the ---unidirectional-new-file option
of GNU diff (used to be -P), if you want deleted files listed, too, you
need -N.
A tarball with a diff -ur, plus added files, and a README explaining
what was done and why may be preferrable to a file-creating diff.
And BTW: it is possible to submit more than one file to an entry in the
patch tracker --- you can add more files later, once the entry is made.
The limit is one file per [Submit] of the page, not one file per
tracker entry.
|
|
From: Daniel J S. <dan...@ie...> - 2006-03-02 18:30:45
|
Lars Hecking wrote: >>How do I commit the changes? I started by CVS downloading > > > Use the patch tracker on SF. Yes, patch tracker... I think the feeling right now is that we are working toward a 4.2 release and do not want to change much or add new features until after that. Mostly maintenance for now. There was a discussion about plot layout in 3D, for which I think there has been no conclusion about what to do. I will take the silence on that to mean that perhaps people would really like to have it done better. That may be too much for 4.2. As an aside, I'd hope that after 4.2 there is a slightly more regular release schedule. I think things have fundamentally changed, where pre 3.8/4.0 there were a lot of bugs that went unnoticed and unattended, to today where there are few bugs and any that are introduced are found and fixed by developers in a day or two. Dan |
