Re: reformatting test blocks

[Rik]

On 02/14/2012 02:46 PM, address@hidden wrote:
> From: "John W. Eaton" <address@hidden>
> To: Jordi Guti?rrez Hermoso <address@hidden>
> Cc: Octave Maintainers List <address@hidden>
> Subject: Reformatting all of the test blocks (cset
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=iso-8859-1
>
> On 14-Feb-2012, Jordi Guti?rrez Hermoso wrote:
>
> | Rik, I was reading the following,
> |
> | http://hg.savannah.gnu.org/hgweb/octave/rev/f3d52523cde1
> |
> | And this changeset is a bit too large to be analysed manually. I
> | wanted to make sure that no semantic changes were made, but it's
> | difficult to know. I didn't see any tests failing nor their number
> | changing, so that gives some reassurance. Still, I would like to have
> | a little more reassurance. I imagine you must have used a program to
> | perform these changes. Can you share that program, if it exists?

I would, if it existed.  Matlab has mlint and it would be nice to have something similar for Octave.  At least least two modes would be valuable for any putative mlint: 1) report on dubious coding strategies like for loops and 2) report on deviations from a preferred Octave style.  The second mode would be useful for core maintainers, but wouldn't be required for all users.  As it is, all of the changes were done manually in a Vim editor.  I do have macros and shortcut keys but the changeset was the product of human, not machine, inspection of the code.  This guarantees that I left in some oddities since my eyes are imperfect.

In any case, the changes were all related and naturally formed one changeset, albeit very large.  I used the same heuristics as you to verify the changeset.  Principally, this meant that 'make check' had to pass.  It would also be useful to execute rundemos on all the script directories, but I did not do that for this changeset.
>
> Also, wouldn't the tests be better if they included some random
> formatting and coding conventions? For example, we would like to know
> that the parser can handle a wide variety of things, not just the
> coding style we prefer.

I think random or pseudo-random testing is a good thing, but as part of an overall test strategy.  There is a whole script devoted to parser tests in the tests/ directory that could be expanded to stress test the parser rather than devolving that randomness to individual test benches.

Octave is referred to as a programming "language" and I believe the analogy to a human language should be taken seriously.  Certainly Octave has words and a grammar -- just like an ordinary language.  It also has developed idioms (collections of words that represent a single idea).  For example, finding the first non-singleton dimension has been done in several different styles.  One style is

[~, dim] = max (sz != 1)

but I find this opaque.  I have been replacing those kind of instances with

(dim = find (sz > 1, 1)) || (dim = 1)

which I find more natural.

If Octave is similar to a human language then I think it is learned in the same way which is through mimickry.  Children copy sounds, and from sounds they move to words, until they get something that approaches what their parents speak.  Octave also explicitly encourages mimickry when we advise following whatever coding conventions can be detected in the source file.  This is fine if the original code represents a high quality sample.  But if the code is full of for loops and other non-vectorized constructs then any new coders will happily propagate bad coding memes.

I started with changesets to update the example code in docstrings and then I moved on to the code in demo blocks.  I figure those areas would have the most influence on new programmers.  In the interest of being thorough, I have moved to the %!test blocks.  My goal is a clean source tree that hopefully will be a good learning reference for this hypothetical wave of new coders expected from releasing an Octave with GUI support and with pre-built Windows binaries.

I'm sure this answer is *way* longer than you anticipated :)

--Rik