From sources-request at octave dot org Fri Jun 18 06:56:39 2004 Subject: Re: Patch for documentation From: David Bateman To: Federico Zenith Cc: sources at octave dot org Date: Fri, 18 Jun 2004 13:52:38 +0200 According to Federico Zenith (on 06/18/04): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi David, > thanks for the feedback. I also noticed I had left some things that should > have been fixed unchanged in buildssic (mostly some at var's missing). > > Alle 12:35, venerd́ 18 giugno 2004, David Bateman ha scritto: > > Ok, there were a couple of build problems with this patch > > > > * is_stabilizable gives the copyright (However it did before Fredrico's > > patch) > > I thought I had fixed this one, I have to double-check... last time the > problem was a missing at end deftypefn, I'll recompile now and fix this one. What I meant for is_stabilizable is that if you type "help is_stabilizable" inside of octave it gives the copyright notice rather than the help string. This was due to the fact that the "Copyright (C)" was missing from the first block in the file. If you change anything do a full build test. Things to look out for is the building of gendoc.cc that identified the \, -> \\, issue and the compilation of the *.texi files to texinfo and postscript. All of the problems I noticed were fixed in the patches I supplied, which were derived from the patch you supplied. I did nothing about the load/save of structures and user-types issue I spotted previously... If you are happy with the patches I sent then use these as I know they build correctly... > > This is perhaps the one thing that needs to be questioned carefully in this > > patch. Do we want to change the definition like this? Why not allow both > > definitions with a flag? So I'd suggest splitting out the changes to > > When correcting toeplitz.m (that had some mistakes in the matrix), I > double-checked the definition of the Vandermonde matrix, that came next, and > found the following page: > http://mathworld.wolfram.com/VandermondeMatrix.html > It's probably an issue about standards, if it is intentional it's alright with > me (I never saw a Vandermonde matrix before and likely never will afterwards, > so...). Perhaps, but any change in functionality must be questioned, since the change you suggest is not backwards compatiable. So the change you suggest will affect others that use this function significantly. There are several cases where you can justify a change like the one you suggested, for instance * The original code was wrong * A competing product does it the way you suggest and this is a compatibility improvement * You keep the old behaviour but add the new behaviour as an option. If the old behaviour is the default it will be easier to deal with. Changeing the default to the new behaviour might be possible but with a well documented warning in the help string that user who run into trouble can find. * Add the new behaviour as a different function and add a warning to the old version that the behaviour is depreciated and to see the new function I haven't looked at the function that much and my warning about discussing the issue further was more generic as the proposed change will cause backwards compatibility problems. I suggest you supply the vander.m patch as a seperately and ask for comments. With an appropriate subject you'll get the right people reading the thread, while this is not sure for a thread on documentation :-) > > But Fredrico, you really need to supply the changelog entry as I'm > > not sure of all that you've done. For example > > Er, "Federico". Don't worry, everybody gets it wrong the first time. :-) Yeah, but I had the name written in front of me in the header of the mail.. > Anyway, I'll work on the changelog this weekend. What scared me was to build > 109 patches and changelogs, if I can make only one that will be easier :-) If the changes are the same in several files then group the changelog entries together to save time. In any case John would do that in his changelog in any case. I'm not sure splitting the patch up would have been that hard, as all of the changes are isolated. The problem would have been tracking 109 patches to see if they had been accepted or not, which would (will) be a real pain. In any case I spent the time to give the feedback as a peer review of the patch so that John might be more confident of accepting the patch (without vander) as a single piece. > Cheers, > - -Federico > > PS- from next posting I'll try to remember to stick to the bugs at mailing list. sources at octave dot org or maintainers@octave.org seem the appropriate place for your mail... Cheers David -- David Bateman David dot Bateman at motorola dot com Motorola CRM +33 1 69 35 48 04 (Ph) Parc Les Algorithmes, Commune de St Aubin +33 1 69 35 77 01 (Fax) 91193 Gif-Sur-Yvette FRANCE The information contained in this communication has been classified as: [x] General Business Information [ ] Motorola Internal Use Only [ ] Motorola Confidential Proprietary