Re: turning "Octave:broadcast" warning off by default

[Carnë Draug]

On 23 February 2015 at 17:36, John W. Eaton <address@hidden> wrote:
> On 02/23/2015 11:57 AM, Michael Godfrey wrote:
>>
>>
>> On 02/23/2015 11:53 AM, Carnë Draug wrote:
>>> Should I replace the warning name then? I don't really mind it, but I
>>> guess others
>>> may be counting on it. Also, if we break backwards compatibility on the
>>> warning
>>> names like that, then there's no point on having automatic broadcasting
>>> throwing
>>> both "broadcast" and "language-extension" while we deprecate the first.
>>> We might
>>> as well only have it throwing "language-extension" warnings.
>>>
>>> Is this ok?
>>>
>>> Carnë
>>
>> I think that this is OK, but maybe you should wait a bit for other
>> comments.
>> Michael
>
>
> I don't think it's necessary to deprecate a warning ID, so I would just
> change it and disable the warning by default.
>
> I'll leave it up to someone else whether we add warnings for other language
> extensions like ++, +=, unwind_protect.  I don't object to such warnings,
> but I have no particular interest in adding them myself.

We already issue warnings for those things.  See the attached path which
also first changes broadcast warning, and then changes the warning ID of
everything to use "Octave:language-extension" instead.

I also reword the warnings to make it more clear that it won't stop Matlab code
from running in Octave.

> Also, for them to be useful, we need a way to exempt code in the Octave core
> from being subject to such warnings.  Perhaps some kind of per-directory
> switch along with a #pragma-like switch for individual files?  Note that the
> per-file switch can't be a run-time thing as some language extensions are
> syntax and should be warned about when the code is parsed.

Sure. But it has always been like this which is why I think this warning is
mostly useless.  Also, please not only something that exempts Octave core or
a directory.  Would be nicer to have the same work well for any piece of
code like a package or even a single function file I send someone.

The problem is that things like this affect the environment of the functions
being called.  Would be really cool if a change for this would also affect
"pkg load" so we could load a package only on that scope.


Carnë

rename-matlab-incompatible-warning.cset
Description: Binary data