octave-maintainers
[Top][All Lists]
Advanced

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

Re: Code sprint in 2015?


From: Rik
Subject: Re: Code sprint in 2015?
Date: Mon, 23 Nov 2015 14:27:43 -0800

On 11/23/2015 10:07 AM, John W. Eaton wrote:
> On 11/23/2015 12:59 PM, Rik wrote:
>
>> Feel free to suggest more themes.
>
> Tests, especially those that improve coverage would be good, but I don't
> know that we have a good automated way to determine code coverage for C++
> when running the test suite, or how easy it would be to add some coverage
> analysis to the Octave interpreter.  My guess is that it would not be too
> hard, but all these kinds of "oh, that should be easy" tasks seem to hit
> some problem or another that makes them harder than first anticipated.

I always like this goal as well.  If you look at fntests.log most of the
remaining m-files without tests are ones with an interactive element, such
as the audioplayer or ui* family of functions.  But I know there are C++
files which contain multiple DEFUN statements, for which there are only a
few BIST tests.  An example of this is data.cc which has 102 functions, but
many of them are without tests.

For true line coverage of the C++ source, Mike Miller showed how the
current test builds can produce this information.  This was at OctConf 2014
in Montreal, and I was able to get it working standalone on my own
machine.  But that was a long time ago and I've mostly forgotten how.

Another possible goal is rationalizing the distribution of functions
between core and Octave-Forge packages.  There are certain functions like
odeplot or evalc that we would like to bring into the core.  And there are
others, like most of the statistics/tests directory, that I would like to
kick out of the core.

--Rik




reply via email to

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