[OctDev] Re: bug in __plt3__.m

[Paul K. <pki...@ki...>]

On Sat, Apr 28, 2001 at 08:52:30AM +0000, Kai Habel wrote:
> I just noticed, that plot3.m doesn't work anymore. The problem is in 
> __plt3__.m where cx is not known. I had to add a line
> cx = columns(x)
> to make it work here locally. 

I was doing things rather in a panic to prepare for a talk mid-April.
Sorry!

Feel free to update my code on sourceforge as you see fit.  That's why
it is there.  

Note that I prefer to place the change notices in the files themselves
rather than the Changelog file one or two levels up the tree.  It makes
it easier to see how a particular function has changed, and it makes it
less likely that conflicts will need resolving on update.  The shared
Changelog almost guarantees conflicts on every update for an active
project.  If we use a standard yyyy-mm-dd numbered date format, then
we can generate the high level Changelog automatically with a simple
perl script.  Only thing we lose is the ability to tag changes across
several files with the same Changelog entry.

Also, the GPL requires the change notice in the file itself:

    2. a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

This only applies if you redistribute the file, not if you post the
changes back into the main distribution so Octave is not in breach of the
GPL.  Matcompat, and by extension octave.sourceforge, gathers files from
many sources, and many of them must be considered to be redistributed.
So rather than figuring out which ones need explicit change notices
in the file and which ones don't, let's just put the change notices
in the individual files and not think about it.

	- Paul