I am running a Matlab compatible script in Octave, so I was awaiting few warnings concerning the '&' and '|' commands and others, so I added the "warning('all','off')" in my now Octave script, but it doesn't seem to do anything... I don't get it, I still get the same warnings!
Any ideas how to solve this please?
PS: I am running the Octave script in batch mode.
It should be warning('off','all') or just warning('off'), your arguments are inverted.
Docs: https://octave.sourceforge.io/octave/function/warning.html
warning ("off", id)
If the first argument is "on" or "off", set the state of a particular warning using the identifier id. If the first argument is "query", query the state of this warning instead. If the identifier is omitted, a value of "all" is assumed.
Obligatory note that it's probably a better idea to address the warnings than turn them off, and that you should at least re-enable the warnings after specific functions where you want to ignore them.
Related
I have a large codebase in Matlab (2021a Update 5, running on Mac) which triggers the warning:
Warning: Integer operands are required for colon operator when used as index.
But there is no information about where this warning is triggered. How can I find out what file and line-number it came from? So I can adress the problem.
Cris Luengo provided an excellent solution in a comment, so I thought I might repeat it and flag the question as answered.
To break the execution at the first line that's triggering a warning, run the following command in the Command Window beforehand.
dbstop if warning
From what I can tell, the following command resets this option.
dbclear all
I am writing a perl script that needs to set a number of environment variables before calling an external program. My code has the form
$ENV{'VAR1'} = "value1";
$ENV{'VAR2'} = "value2";
When running this through perlcritic, I get a severity 4 violation for every such assignement:
^Magic variable "$ENV" should be assigned as "local"
Googling that error message didn't give me any good solutions. The perlcritic violation that complains in that case is Variables::RequireLocalizedPunctuationVars, and the example given deals with localizing a file handle. I tried to find the relevant section in Perl Best Practices, but it only talks about localizing package variables.
One solution I tried is to localize %ENV using the following statement before the assignments.
local %ENV = ();
This doesn't resolve the violation.
My question is the following:
Is that Perlcritic violation even relevant for assignments to %ENV, or can I ignore it?
If it's relevant, what's the best way to resolve it?
Perlcritic warnings are not The Word of God. They are simply warnings about situations that, if managed incorrectly, could get you into trouble.
Is that Perlcritic violation even relevant for assignments to %ENV, or
can I ignore it?
This warning tells you that:
Global Variables have the very real possibility of action at a distance.
This possibility is even more dangerous when dealing with those variables that change the operation of built in functions.
Is that relevant for %ENV? If you spawn more than one child process in your program, Yes. If someone changes your program later to spawn another child, Yes.
If it's relevant, what's the best way to resolve it?
Now here is where being the human being becomes important. You need to make a value judgement.
Possible actions:
Ignore the warning and hope that future maintainers aren't bitten by your usage of this Global Variable.
Change your code to avoid the situation you are being warned about. The syntax suggested by choroba is a fine option.
Now if you have made a change, are still getting the warning, and believe that the warning is now in error, you can do one or more of:
Be a good citizen and Submit a bug report.
use the comment ## no critic (RequireLocalizedPunctuationVars) on the affected lines or on it's own line before the lines in question.
Or more excessively disable the rule or just create an exception for %ENV in your .perlcriticrc file.
You can localize the value for the given environment variable only:
local $ENV{VAR1} = 'value1';
Consider using Env. perlcritic does not complain about the variable:
use warnings;
use strict;
use Env qw(VAR);
$VAR = "value1";
I'm minimizing a function with the fmincon routine.
This function uses the integral command several times. However, some of those integrals turns out to be Inf or NaN and I don't want MATLAB to show a warning when this happens (the function is always finite).
I've tried using the command warning('off','MATLAB:integral:NonFiniteValue') but it don't seem to be working when running the optimization.
It could be you're simply suppressing the wrong message. You could inspect the values of
[a,b] = lastwarn
inside an output function (opts = optimset('OutputFcn', #myOutFcn);) to make 100% sure you're killing the correct warning message.
But I too have encountered this annoying behavior before -- you just can't seem to suppress certain warnings in MATLAB's own functions. For those, you have to resort to ugly and fragile hacks.
You could try
warning off
...
warning on
which suppresses all warnings for all code contained in the '...' section.
You could also use an undocumented feature: temporarily promote the warning to an error:
ws = warning('error', 'MATLAB:integral:NonFiniteValue');
...
warning(ws);
and wrap it up in a try....catch. Chances are you then interrupt integral and thus fmincon prematurely and will thus have to wrap it up together with some rescue mechanism, but that gets real complicated and real ugly real fast, so that's only to be used as a last resort...
...so in all, it's easiest to just live with the warnings.
There's an alternative way: click on the uppermost link in inner matlab files that produced that warning, find warning ID & copy it into clipboard.
Then add the following line to your script:
warning('off','IDHERE');
Replace IDHERE with actual ID
See https://tushev.org/articles/blog/17/how-to-suppress-matlab-warnings
When using IPython, it's often convenient to see how long your commands take to run by using the %time magic function. When you use this often enough, you start to wish that you could just get toggle a setting to get this metadata by default whenever you enter a query. Psql lets you do this with \timing. GHCi lets you do this with :set s+. Does IPython let you do this? And if not, why not?
The "ipythonic" way of timing code is using the %timeit or %%timeit magic function (respectively for online, and multi-line code).
These functions provide quite accurate results by running the code multiple times (the exact number is adaptive if not specified).
The global flag you are asking does not exist in ipython. Furthermore, just adding %%timeit to all the cells will not work because global variables are not modified when calling %%timeit. This "feature" is directly inherited from the timeitmodule.
For more info see this ipython issue.
As a Perl beginner I am sometimes getting compilation errors and have to search a lot to find it. In the end it is just a missing semicolon at the end of a line. Some syntax errors with missing semicolon are checked by Perl but not in general. Is there a way to get this check?
edit:
I know about Perl::Critic but can't use it atm. And I don't know if it checks for missing semicolon in general.
Because semicolons actually mean something in Perl and aren't just there for decoration, it's not possible for any tool (even the Perl interpreter itself) to know in every case whether you actually meant to leave off the semi-colon or not. Thus, there's no general-case answer to your question; you'll just need to go through your code and make sure it's correct.
As mentioned in my comments, there are various tricks you can try with your editor to expedite the process of finding potentially-incorrect lines; you must, however, either examine and fix these by hand or risk introducing new problems.
The syntax check is perl -c, but that's no different than attempting to run the program outright. Due to its flexible/undecidable syntax, one cannot generally do what you want. That's the downside of comfort and expressiveness.
Upgrade to the latest stable Perl, the parser's error messages got better/more exact over the last years and will correctly recognise many circumstances of a missing semicolon.
Rule of thumb that works for many parsers/other languages: if the error makes no sense, look a couple of lines before.
use diagnostics; usually gives you a nice hint, same as use warnings;. Try to keep a consistent coding style, check perlstyle.
Also you can use Perl::Critic online.
Also as general advice learn how to use packages and modules, try to group code into subs and study the syntax of arrays, lists and hashes. A common mistake is forgetting the ; after an anonymous hashref assignment:
my $hashref = { a => 5, b => 10};