I am trying to compile a sample jsoncpp example, but there are tons of compiling errors showing up in "standard" headers. did any body see this any time ?
[~]$ g++ -g -c json.cc -I/usr/local/include/json
In file included from /usr/include/libio.h:62,
from /usr/include/stdio.h:75,
from /usr/lib/gcc/i686-redhat-linux/4.4.6/../../../../include/c++/4.4.6/cstdio:45,
from json.cc:1:
/usr/include/sys/cdefs.h:46:44: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:50:44: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:135:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:151:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:209:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:218:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:227:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:236:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:248:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:258:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:267:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:275:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:289:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:297:43: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:326:19: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:338:20: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:343:20: error: missing binary operator before token "("
/usr/include/sys/cdefs.h:350:19: error: missing binary operator before token "("
In file included from /usr/lib/gcc/i686-redhat-linux/4.4.6/../../../../include/c++/4.4.6/cstring:45,
from json.cc:2:
For me it was the features.h included with json-cpp conflicting with the system features.h in some other includes. I renamed it locally to json_features.h in the json-cpp code and all was well.
You need to include header file using this way:
#include "json/json.h"
If you compile with -I.../include/json, then the standard library might accidentally include a JSON header. (In this case, according to asuter, it was features.h.)
The parent directory is a kind of "namespace" for header files. That's why a good practice for any library with headers like incdir/foo/bar.h is -Iincdir and #include <foo/bar.h>.
Check JSON include path. In compilation option use -I/path of JSON include directory, e.g. -I$(pkg-config --cflags jsoncpp).
That's the kind of thing that would happen if one of your headers that preceded it had a syntax error such as a missing ; at end of class declaration. Start by cleaning those.
Related
I'm trying to update large complexe json files and exit with detailled error message when detecting incoherent data (with jq 1.6).
I started to use functions and try/catch to produce a kind of java stacktrace containing input data from each level => easy, thank you JQ
But when I started to update array elements (using |=), I didn't find the solution
Here is a very simple example :
echo '{"array": [{"foo":"bar"}]}' | jq -c '.array[] |= try . catch (.)'
output : {"array":[{"__jq":0}]}
Do I made a mistake ? Is it a normal behaviour ?
Thanks for your help
The try-catch isn't really an expression, it yields no meaningful value, it merely executes some expression:
try-catch
Errors can be caught by using try EXP catch EXP. The first expression is executed, and if it fails then the second is executed with the error message. The output of the handler, if any, is output as if it had been the output of the expression to try.
emphasis mine.
So it would be wrong to use the value, you should perform the assignment within the try expression.
$ echo '{"array": [{"foo":"bar"}]}' | jq -c 'try (.array[] |= .) catch (.)'
You have stumbled upon a bug in jq 1.6. Using jq 1.5, one obtains the correct output:
{"array":[{"foo":"bar"}]}
However, the expression .array[] |= try . catch (.) is not one would ever use in practice, because if .array is a JSON array or JSON object, it just says: do nothing.
To understand try ... catch ..., it might help to consider this example:
$ jq -n 'try error("abc") catch ("The error message was " + .)'
"The error message was abc"
first time posting here. I've a feeling that this is a really dumb question, but for some reason my code keeps failing and I just can't put my finger on what's wrong.
Here's is what I have:
*** Settings ***
Library Selenium2Library
Library OperatingSystem
Library String
Library Collections
*** Test Cases ***
Test Robot Framework Logging
#{ALLOWED}= Create List /page1 /page2 /page3
${ControllersList}= Get File ${EXEC_DIR}/Resources/controllers.txt
#{PAGES}= Split to lines ${ControllersList}
:FOR ${PAGE} IN #{PAGES}
\ Run Keyword If '${PAGE} IN #{ALLOWED}' Log Testing WARN
[Teardown] Close Browser
This is the output:
Evaluating expression ''/page1 IN [u'/page1', u'/page2', u'/page3']'' failed: SyntaxError: invalid syntax (<string>, line 1)
If I change the condition to something like this it works:
'${PAGE} == /page1'
I checked the documentation and it seems that the IN condition could be used. I'm totally lost here. Any hints? Thanks!
This is the proper way to do the expression:
Run Keyword If $PAGE in $ALLOWED Log Testing WARN
By removing the quotes and the curly braces, robot is able to treat PAGE and ALLOWED as python variables when evaluating the expression.
From the section Evaluating Expressions in the documentation for the BuiltIn library:
Starting from Robot Framework 2.9, variables themselves are automatically available in the evaluation namespace. They can be accessed using special variable syntax without the curly braces like $variable. These variables should never be quoted, and in fact they are not even replaced inside strings.
Also, when using keywords like Run Keyword If, the expression must be a valid python expression after variable substitution. Therefore, you must use the operator in rather than IN. The latter is used only by the robot :FOR statement.
Example
*** Variables ***
#{ALLOWED} /page1 /page2 /page3
*** Test Cases ***
Example that passes
${PAGE}= set variable /page1
Run Keyword If $PAGE in $ALLOWED
... pass execution ${PAGE} is allowed
fail ${PAGE} is not allowed
Example that fails
${PAGE}= set variable /page99
Run Keyword If $PAGE in $ALLOWED
... pass execution ${PAGE} is allowed
fail ${PAGE} is not allowed
The check was almost right, but you've effectively turned the Boolean expression into a String by surrounding it with the quotes. Here's the syntax that'll do it:
\ Run Keyword If $PAGE in $ALLOWED Log Testing WARN
Mind there are no curly brackets {} around the variable names - thus the check is (almost) the straight python's variable in another_variable
The documentation Evaluating Expressions does indeed specify that in construction used in the evaluation itself. An alternative approach is to use the Collections library keyword Get Match Count. This will return 0 when no results are found, and not generate a test failure.
*** Settings ***
Library Collections
*** Test Cases ***
Test Robot Framework Logging
#{ALLOWED}= Create List /page1 /page2 /page3
#{PAGES}= Create List /page1 /page3 /page5
:FOR ${PAGE} IN #{PAGES}
\ ${InList}= Get Match Count ${ALLOWED} ${PAGE}
\ Run Keyword If ('${InList}' == '0') Log To Console Page Not Allowed
\ ... ELSE IF ('${InList}' == '1') Log To Console 1 Page Found
\ ... ELSE Log To Console More pages found.
I get this warning:
WARNING - restricted index type
found : string
required: number
someArray[ index ].doSomething();
This happens after a closure compiler upgrade to the latest version.
It looks like the use of a string type indexes for arrays are not recommended by closure compiler.
What would be the recommended solution to this problem?
BTW. Is there a way to disable check for these warning types (I looked through the CC flags list and can't find anything)?
If your index variable is of type string, you should parse it first.
Try
someArray[parseInt(index)].doSomething();
Additionally, I assume that the reason it's a string in the first place is that it comes from somewhere like a DOM attribute or an HTML input. You might want to make sure the value is valid, before using it.
const parsedIndex = parseInt(index);
if (isNaN(parsedIndex) || index < 0) {
throw 'Invalid index';
}
someArray[parsedIndex].doSomething();
I'm parsing with common lisp library meta-sexp.
When I call a rule like this (entity? (create-parser-context str)), I'm not getting any error if the str is invalid. How to get the errors displayed?
A non-match is not an error unless a rule (entity?) or the code calling it programs a non-match as failure.
See the readme. There is an example rule integer-debug?, in the center of the document, that uses a callback to report the character and position of input that failed to parse an integer.
Since rules return NIL on no-parse, to signal a fatal error: (or (entity? (create-parser-context input)) (error "Input is bad!)) could be used to bail out with an error message from an irrecoverable input error.
Here is a piece of my bnf grammer.
//this works
<ter-stmnt> ::= <rval> '?' <rval> ':' <rval>
//this gets an error
<ter-stmnt> ::= <bool-val> '?' <rval> ':' <rval>
<bool-val> ::= <rval>
This seems insane, shouldnt the second be EXACTLY the same as the first? i prefer the second bc when reading i see that i expect a bool value as oppose to the generic rval which can mean anything.
I am using Gold Parser 3.4.4
The error that you're getting is:
Reduce-Reduce Conflict
'?' can follow more than one completed rule. A Reduce-Reduce error is a caused when a grammar allows two or more rules to be reduced at the same time, for the same token. The grammar is ambigious. Please see the documentation for more information.
It's saying that after it's evaluated some tokens, it's unable to decide whether it's just read a <bool-val> or whether it read an <rval>.
To make more sense your grammar ought to say what a <bool-val> is, specifically, and then say that an <rval> is a <bool-val> or other things.
Here's another example of a reduce/reduce error, and here's the GOLD documentation. Gold will try to hide (i.e. emit a warning instead of an error) about a shift/reduce, but it treats reduce/reduce as an error.
I don't entirely understand this; I'm new to parsing. Maybe you're right about this being unexpected behaviour? However the GOLD mailing list seems to be down at the moment, perhaps because it's moderated and Devin has been offline for months.
What error do you get? Can you include your whole grammar file? I don't get any error if I declare rules like ...
<ter-stmnt> ::= <bool-val> '?' <rval> ':' <rval>
<bool-val> ::= <rval>
<rval> ::= '!'