octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test scripts


From: Paul Kienzle
Subject: Re: test scripts
Date: Tue, 2 May 2000 05:10:32 +0100 (BST)

>From: "John W. Eaton" <address@hidden>
>On 28-Apr-2000, Thomas Walter <address@hidden> wrote:
>
>| I looked at the patches for improvement.  Cuurently the most testing
>| code for vectors and matrices uses a syntax like:
>|      [1 2 0]
>| It would be much clearer and better to use
>|    [1, 2, 0]
>| then it works with 
>|      whitespace_in_literal_matrix = "ignore"
>| as suggested in the octave manual.
>
>I sent mail to Paul requesting the following changes:
>
>  The patches for hilb and vander wipe out the Texinfo comment
>  header.  I'd rather preserve them.
>
>  When writing code for Octave, can you please use Octave conventions?
>  Things like double quotes for strings, surrounding assignment
>  operators with spaces, a space between function names and the opening
>  paren for the argument list and also after commas in the arg lists,
>  parens around conditions in if and while statements, using `!' instead
>  of `~' and `!=' instead of `~=', and using the short-circuit || and &&
>  operators where appropriate.
>
>  These things may seem like silly details, but it makes the sources
>  easier for me to read, and since I'm the default maintainer of
>  everything in Octave, I find it important enough that I usually end up
>  doing it myself, and that just slows down the process of including
>  patches.
>
>I've also been having a discussion with Etienne Grossmann about how to
>speed up acceptance of patches.
>
>I admit that I am sometimes slow and unresponsive.  Part of the
>problem is that I am busy.  Part of the problem is that the patches
>often have problems.  I hope that we can arrive at some way to make
>things go faster.

There are a two ways to deal with problem patches.  One is to aggressively
train people to produce patch the way you want by rejecting any that
don't meet your standards.  The other is to deputize.  That is, let 
a few others massage patches and interact with submitters, then send
you clean patches to decide upon.  So far this style is working for the
kernel, and it has A LOT more activity than octave.

Another thing you can do is adjust your acceptance standards.  If you
are particularly concerned about the format of code, then write a
pretty printer to format it exactly the way you want it.  That way we
can continue to code in the style that we've evolved over 20 years of
programming with out jeopardizing the consistency of the package.

The bigger problem to my mind is deciding if the patches produce
correct code.  A testing mechanism that mere dabblers can use with
most of the tests already defined is a big step in the right direction.
I've needed enough brown bags in my few submissions that I'm motivated
to work on it.

>
>I'm concerned that applying any patch no matter how it is written,
>will make the sources less coherent, harder to read, and ultimately,
>harder to maintain.  It would help me if people would follow the
>coding conventions of the existing Octave sources when submitting
>patches, but I'd like to know whether people think it is an
>unreasonable request.
>
>Thanks,
>
>jwe
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]