octave-maintainers
[Top][All Lists]
Advanced

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

Re: function definitions in tests


From: David Grundberg
Subject: Re: function definitions in tests
Date: Tue, 19 Jan 2010 09:04:16 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090812)

John W. Eaton wrote:
On 18-Jan-2010, Thorsten Meyer wrote:

| John W. Eaton wrote:
| > On 18-Jan-2010, David Grundberg wrote:
| > | > | This might have to do with changes I did to the interpreter (after 3.2). | > | I know I changed eval_string() to require function definitions to have | > | endfunctions. I think this is a good thing when calling eval.m. But with | > | tests, the block is defined by the indention and that should suffice. | > | I'm pushing a changeset to fix this. | > | | > | http://hg.savannah.gnu.org/hgweb/octave/rev/e68431e60e3d | > | > But now there will be failures if the test includes an explicit
| > endfunction, because you have added one unconditionally.
| > | > Perhaps we should just fix the tests so that they have explicit
| > endfunction tokens, or look for some other solution to the problem?
| > If the tests fail when run from the command line, why do they succeed
| > when run as part of make check?  What is the difference between those
| > two cases?
| > | Without Davids patch, the behaviour of the fntests.m script is completely
| mysterious to me:
| When I run it like it is run in the build process, i.e.
|       octave  --norc --silent --no-history fntests.m
| the tests do not complain about missing endfunction
| | However, when I run it like this:
|       octave  --norc --silent --no-history
|       octave> fntests
| | I get lots of missing endfunction errors. I also get them, when I wrap the
| fntests call into a function or start it with eval("fntests").
| | regards | | Thorsten


I think the difference is happening because when Octave is reading the
fntests.m script, the variable "reading_script_file" is set to true,
so the following test in the parser does not succeed, and the EOF at
the end of the eval string used by the test function is accepted as
the end of the function instead of triggering the error.

                    if (! reading_fcn_file && ! reading_script_file)
                      {
                        yyerror ("function body open at end of input");
                        YYABORT;
                      }

How about the following change instead of unconditionally appending
endfunction?  It seems to work for me, and should allow functions to
work in tests with or without endfunction tokens.

  http://hg.savannah.gnu.org/hgweb/octave/rev/0c3609dd34cf

jwe

I changed eval_string on purpose to disallow open function bodies on EOF. Open ends are IMHO a bad construct that are especially confusing when several functions are defined. I don't think application writers should rely on eval () allowing open ends.

On the other hand, I think it's clear that %!function blocks are ended with their indention, they don't need an endfunction. If we allow an endfunction token, then we should reasonably also support this syntax:

%!function foobar()
%!  # indented function body
%!functionend

But this doesn't work well with test.m as it is now, because it reads indention, it doesn't analyse syntax.

Regards,
David


reply via email to

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