octave-maintainers
[Top][All Lists]
Advanced

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

Re: test failures with current mercurial sources (was Re: 3.0.1 release?


From: John W. Eaton
Subject: Re: test failures with current mercurial sources (was Re: 3.0.1 release?)
Date: Thu, 03 Apr 2008 11:15:32 -0400

On  3-Apr-2008, David Bateman wrote:

| Yes that might be a nice feature, but I think you'd then also need
| 
| warning ("clear", "Octave:deprecated-function");
| 
| so that the fact that the warning has already appeared might be
| cleared..

Couldn't the existing "warning on|off" do that job?

| Will the fact that there are a large number of named warning
| make things slower however? If so I think I'd prefer to forgo it..

I could be wrong, but I think most warnings are only issued if some
condition is met.

For the case of using a deprecated function that would produce an
unconditional warning, I don't think it matters that it is slower.  We
want people to move away from the deprecated functions anyway, so it
is just extra incentive if switching improves performance.

In any case, when warning_with_id is called it does quite a bit of
work and performs a linear search over all the elements of
warning_options.  So yes, that could probably be improved.  The
internal warning_state variable is a map, so I don't remember why it
is searched linearly.  I guess because it is a structure array with
elements "identifier" and "state" rather than a map from identifier to
state.  Maybe we could change the internal representation to provide
better performance while still providing the struct array format for
compatibility, only generating it when requested.

The simple thing is to add the persistent variables to the deprecated
functions as you suggested.  I don't object to that, but you asked
whether there was another way.

jwe


reply via email to

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