Warning INI parameter missing in Z3 3.2? - configuration

According to the list of INI parameters there should be a boolean WARNING flag, but setting it in Z3 3.2 (x64_mt) via
(set-option :WARNING false)
yields unsupported for both spellings WARNING and warning.
Are the docs outdated or I am doing something wrong here?
[EDIT]
According to the release notes of Z3 2.17 the option should be set via
(set-option WARNING <flag>)
but trying
(set-option WARNING false)
yields
(error "line 1 column 13: invalid command argument, keyword expected")

Ok, seems as if the docs are outdated. I finally found
(set-option :print-warning false)
in this answer and it works.

Related

How to solve or suppress wall of warnings using any pystan code

When I run any pystan code, the output is what I expect, but I get a wall of warnings.
I've tried updating pystan and cython, as these are mentioned in the wall of warnings. My pystan is now version 2.17.1 and cython 0.29.2. I'm running python3.7.
import pystan
model_code = 'parameters {real y;} model {y ~ normal(0,1);}'
model = pystan.StanModel(model_code=model_code) # this will take a minute
y = model.sampling(n_jobs=1).extract()['y']
y.mean() # should be close to 0
The error message that I get starts with:
/home/femke/anaconda3/lib/python3.7/site-packages/Cython/Compiler/Main.py:367: FutureWarning: Cython directive 'language_level' not set, using 2 for now (Py2). This will change in a later release! File: /tmp/tmp8_plkepg/stanfit4anon_model_5944b02c79788fa0db5b3a93728ca2bf_5335140894361802645.pyx
tree = Parsing.p_module(s, pxd, full_module_name)
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
In file included from /home/femke/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1823:0,
from /home/femke/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:18,
from /home/femke/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
from /tmp/tmp8_plkepg/stanfit4anon_model_5944b02c79788fa0db5b3a93728ca2bf_5335140894361802645.cpp:688:
/home/femke/anaconda3/lib/python3.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
#warning "Using deprecated NumPy API, disable it by " \
^~~~~~~
In file included from /home/femke/anaconda3/lib/python3.7/site-packages/pystan/stan/lib/stan_math/lib/boost_1.66.0/boost/numeric/ublas/matrix.hpp:19:0,
from /home/femke/anaconda3/lib/python3.7/site-packages/pystan/stan/lib/stan_math/lib/boost_1.66.0/boost/numeric/odeint/util/ublas_wrapper.hpp:24,
from /home/femke/anaconda3/lib/python3.7/site-packages
Is this something to worry about? If not, how do I specifically disable these warnings, but not from other parts of my code? If so, what should I change.
Edit: after having read the question Cython Numpy warning about NPY_NO_DEPRECATED_API when using MemoryView, I still don't know how to safely disable this warning.

TCL issues with Octal numbers seen after porting from EDK 1.05 to EDK2

I have an EFI Shell tool which uses EDK 1.05 and TCL 8.3 sources. This tool accepts user commands to display PCI-E adapter information and to upgrade firmware on it. I recently ported it to UDK2017. I am using VS2012x86 toolchain to build the tool.
When I run the binary from EFI Shell, TCL reports errors such as these.
can't use invalid octal number as operand of "||"
syntax error in expression "(1<<0)"
syntax error in expression "(0x1<<0)"
I have read about TCL and Octal numbers
Since this issue is not being seen with EDK 1.05 code with the same TCL version, I am wondering if there is any flag I am missing out. I am hoping there is a simple solution to get past this error since there was no change in the TCL version.
Octal Issue
It's hard to be sure, but I suspect with the octal number issue you've got code that's parsing something like 080808 as a number, which is interpreted as octal because of the leading 0 (just like a constant in C or C++) and so can't contain an 8 (or 9). To parse a number definitely as decimal, the scan command is used:
set val 080808
scan $val "%d" parsedVal
# Properly, should check that [scan] has a result of 1, but I probably wouldn't bother
puts "$val -> $parsedVal"
Odd Expression Syntax Error
The other syntax error in expression "(1<<0)" errors are stranger, as those are definitely valid syntax. I've only got versions back to 8.4 on this machine, but…
$ tclsh8.4
% expr (1<<0)
1
The only ways that could be an invalid expression are if it is either in some custom expression language (which would be application-specific; you'll have to read the documentation to figure that out) or if you're using an expression string as a numeric value:
% set val (1<<0)
(1<<0)
% expr {$val + 1}
can't use non-numeric string as operand of "+"
but that wouldn't produce exactly the error you are seeing. Very puzzling indeed!
Use Stack Traces
There is something that might help you figure out what is going on. After an error, the global errorInfo variable has a stack trace generated. For example, after the above erroring expr it has this:
% puts $errorInfo
can't use non-numeric string as operand of "+"
while executing
"expr {$val + 1}"
The good thing is that this tells you exactly what command and where gave you the error; that can make a gigantic difference in your detective work to hunt down your problems.

Janino: Script won't compile (cook) if ! operator is used

I am having a problem compiling (cook) following Janino script.
(((sfv1.equals(a_p))))&&(((sfv2.equals(a_ac))))&&(((!(a_d~~bfv3))))
I am passing parameter types for [sfv1, a_p, sfv2,a_ac, a_d~~bfv3], where a_d~~bfv3 is a Boolean type and rest are Strings.
I am seeing following error when I tried cook the script.
org.codehaus.commons.compiler.CompileException: Line 1, Column 0: ')' expected (compiler.err.expected)
I have tried changing the script to following, with the same result:
(((sfv1.equals(a_p))))&&(((sfv2.equals(a_ac))))&&(((!(a_d~~bfv3==true))))
I am wondering if Janino doesn't have support for Boolean type parameters.
Can any one help me with this?
'~' is a pre-defined operator in Janino. This was the reason for the error. When '~' was found, Janino was expecting matching ')' for '('.
Replacing "~~" with "__" resolved the issue for me.

After update of the JSON module i get the following warning

After update of the JSON module from version 1.54 to 2.07 i get the following warning in my logs:
Prototype mismatch: sub ModPerl::ROOT::ModPerl::PerlRun::mypath_myfile_2epl::from_json: none vs ($#) at mypath_myfile.pl line 6.
Prototype mismatch: sub ModPerl::ROOT::ModPerl::PerlRun::mypath_myfile_2epl::to_json: none vs ($#) at mypath_myfile.pl line 6.
Prototype mismatch: sub ModPerl::ROOT::ModPerl::PerlRun::mypath_myfile_2epl::encode_json: none vs ($) at mypath_myfile.pl line 6.
Prototype mismatch: sub ModPerl::ROOT::ModPerl::PerlRun::mypath_myfile_2epl::decode_json: none vs ($) at mypath_myfile.pl line 6.
in line 6 of myfile.pl use JSON; is called
Any ideas what's going wrong here or how to solve this issue?
Check the incompabilities between JSON 1 .x and 2.x at CPAN.
What do you include before JSON? Which modperl version are you running?
Sounds like you also need to update your JSON::XS and/or JSON::PP to a compatible version.

Strict Standards: Creating default object from empty value. What does this error message mean?

I get this error message:
"Strict Standards: Creating default object from empty value in /opt/lampp/htdocs/projects/nusoap/lib/nusoap.php on line 76 "
The code on line 76:
$GLOBALS['_transient']['static']['nusoap_base']->globalDebugLevel = 9;
What does this mean? And how can I fix it.
Looking forward to your reply
Regards
SirBT
You can set the error_reporting level to strict just before include nusoap library:
ini_set('error_reporting', E_STRICT);
require 'nusoap.php';
I fixed the problem by replacing the nusoap.php file with a an older version specifically nusoap.php 0.95.
The PHP environment I work in is: PHP 5.3.8, nusoap.php 0.95 seems to be compatible with PHP 5.3.8. My conclusion is that the: "Strict Standards: Creating default object from empty value in /opt/lampp/htdocs/projects/nusoap/lib/nusoap.php on line 76" is a compatibility issue.