Notice: A non well formed numeric value encountered in mail.php in opencart - opencart2.x

Notice: A non well formed numeric value encountered in /home/demouser/public_html/abc/system/library/mail.php on line 170Notice:
This error show after calling payment getaway.

The error is self explanatory. Probably you are doing some math without the proper brackets / integer / float values.

Related

Difference between .append() and += in python

I'm working on LeetCode 78. Subsets and found this interesting error. If I change the marked line to the commented line, such an error will be thrown out.
I announced "res" in the outer function, why is res.append() different from res += ? I know += is more like .extend() but that is not the conflict here. What caused the reference error?
Of course it will throw an error. +=1 only applies to One number, whether it being an integer or a float or a decimal. The fact that python do not force you to declare the type of a variable does not mean that you can apply the method of one type to another on your own imagination. And append is restricted to lists, applying it to a number you will also get an error.

Geoserver, string parameter sending by using viewparams values

Is it possible to send a string value to SqlView based layer in the viewparameter sequence? My parameter is similar to date (contains dashes) and if I put it in request like this:
http://x.y.z/geoserver/db/wms?service=WMS&version=1.1.0&request=GetMap&layers=ABC:AnyDay&styles=&bbox=2069724.275423,7237025.845297,2069831.088769,7237123.162091&width=768&height=699&srs=EPSG:3857&format=image%2Fgif&viewparams=XYZ:2017-10-10
server gives error information: XYZ is integer and SQL query is bad - no layers appear.
I know this solution is dangeoreus but I have to agree with it.
As error given by geoserver. It seems variable XYZ is of integer type and you are passing argument non integer type. This type error came due to type mismatch.

How to represent a missing xsd:dateTime in RDF?

I have a dataset with data collected from a form that contains various date and value fields. Not all fields are mandatory so blanks are possible and
in many cases expected, like a DeathDate field for a patient who is still alive.
How do I best represent these blanks in the data?
I represent DeathDate using xsd:dateTime. Blanks or empty spaces are not allowed. All of these are flagged as invalid when validating using Jena RIOT:
foo:DeathDate_1
a foo:Deathdate ;
time:inXSDDatetime " "^^xsd:dateTime .
foo:DeathDate_2
a foo:Deathdate ;
time:inXSDDatetime ""^^xsd:dateTime .
foo:DeathDate_3
a foo:Deathdate ;
time:inXSDDatetime "--"^^xsd:dateTime .
I prefer to not omit the triple because I need to know if it was blank on the source versus a conversion error during construction of my RDF.
What is the best way to code these missing values?
You should represent this by just omitting the triple. That's the meaning of a triple that's "not present": it's information that is (currently) unknown.
Alternatively, you can choose to give it the value "unknown"^^xsd:string when there's no death date. The solution in this case is to not datatype it as an xsd:dateTime, but just as a simple string. It doesn't have to be a string of course, you could use any kind of "special" value for this, e.g. a boolean false - just as long as it's a valid literal value that you can distinguish from actual death dates. This will solve the parsing problem, but IMHO if you do this, you are setting yourself up for headaches in processing the data further down the line (because you will need to ask queries over this data, and they will have to take two different types of values into account, plus the possibility that the field is missing).
I prefer to not omit the triple because I need to know if it was blank
on the source versus a conversion error during construction of my RDF.
This sounds like an XY problem. If there are conversion errors, your application should signal that in another way, e.g. by logging an error. You shouldn't try to solve this by "corrupting" your data.

Converting character to real fails if character consists of an integer (i.e. without dot)

I am reading a text file with my fortran code. I parse the text file (which contain a bunch of stuff such as names and numbers) and I end up with strings containing real number (they are real time measuraments) such as:
string = 1.34
I simply write this string in a real number by doing
read(levelCHAR,'(f)') level
And everything worked great for a month until today, when the number in the input file was exactly 1 and I had:
string = 1
and the read statement above gave me
level=0
Therefore to fix this I added before the read statement:
if (index(string ,'.')<=0) then
string = trim(string )//'.'
endif
And this seems to have fixed the issue. However, I wanted to know if I am missing something and there is a more elegant way to do this in one line for example by replacing the format '(f)' in the read statement with a more suitable expression.
Your program is not valid Fortran:
read(levelCHAR,'(f)') level
1
Error: Nonnegative width required in format string at (1)
form.f90:5.5:
You must indicate the input field with such as f5.0. Or you can use the list-directed input read(levelChar,*) level.
Also, be sure to use the .0 and not any other number in the fw.d descriptor for input. Otherwise strange results are to be expected for integer inputs as they will be multiplied by 10**(-d).

An alternative to offest = "-1" in Expression Engine

Does anyne know how expression engine deals with a negative offset in a list of channel entries in EE?
as in
offset="-1"
If you use offset="-1" in {exp:channel:entries}, you'll get a major MySQL error (assuming you're logged in as a super admin or are capable of seeing errors).
It's unclear what your goal is from your question. If you expect a negative offset to reverse the order (like PHP string functions), you can use use the opposite sort value. The default is desc, so sort="asc" would be the reverse. Use a positive offset="X" to skip X entries.
If you're expecting an offset like in PHP array_slice where you're still going "forward" but a negative offset starts you X entries from the end, I don't believe there's a direct comparison.
The goal was to work with the preceding chanel entry on the same page as the current channel entry.
I managed to do it instead by pulling out the relevant entry_ids and processing them in php and then put them back in with a fixed_order attribute

Resources