BEGIN BLOCK BLK_ROWDEC
NAME cell_rowdec
SIZE UNI_rowdecSize
ITERATE itr_rows
DIRECTION lgDir_rowdec
STRAP STRD1,STRD3,STRD2
WRAP WRD1
VIA VIAB,VIAC,VIAD
ENDS BLK_ROWDEC
I want to parse this using flex and bison such that it matches block name of BEGIN and ENDS. And it finds both are equal then only parse. So how can it is possible with flex and bison please help me out.
From long times I am stuck with this problem. Please help me.
Thank you so much.
If I understand correctly, it's all about the begin/end pairs with a name.
If you have a context free grammar, you'll have begin/end pairs that match, like in
text := block
| text block
;
block := BEGIN BLOCK blockname blockcontents ENDS blockname
;
blockcontents := item
| blockcontents item
;
item := block
| VIA vialist
| WRAP wrapname
...
Now if you look at the production of block, you'll note that the name occurs twice. In your action you can check equality. If both names are equal, fine, if not, you have a syntax error. Ignoring everything since the opening "BEGIN BLOCK" is one strategy to cope with the syntax error.
(If I'm not mistaken, the condition that the names must match makes the grammar not context free, but since the condition is very simple, I'd categorize it as "almost context free" ;)
If your text allows several blocks to be mixed, you have a grammar that is not context free and is much more difficult to parse (though not impossible).
You still can use lex/yacc resp. flex/bison, but it'll require a lot more bookkeeping from your side.
Still, the first thing you need is a grammar. My (partial) example above could be a start.
You can use bison/yacc syntax to specify your grammar. That would reduce a bit of effort.
Related
I am still a bit new to the robot framework but please rest assured I am constantly reading its User Guide. I am a bit stuck now with one test case.
I do have a list of individual words, that I need to verify on a page, mostly German translations of field labels if they appear correctly or are found in an element at all.
I have created a list variable as follows:
#{GERMAN_WORDS} | Benutzer | Passwort | Sendung | Transaktionen | Notiz
I have the following locator that contains the text labels on the webpage, and the one I need to verify:
${GENERAL_GERMAN_BOARD} |
xpath=//*[#id="generalAndIncidents:generalAndIncidentsPanel"]
I would like to check every single word one by one from the list variable, whether they are present in the locator above.
I did create the following keyword for this purpose, however I might be missing something because it calls the entire content of my list variable, instead of checking the words from it one by one:
Block Text Verification
[Arguments] ${text_list_variable} ${locator_to_check}
Wait Until Element is Visible ${locator_to_check}
FOR ${label} IN ${text_list_variable}
${labelTostring} Convert to String ${label}
${isMatching} = Run Keyword and Return Status Element Should Contain ${locator_to_check} ${labelTostring}
Log ${label}
Log ${isMatching}
Exit For Loop If '${isMatching}' == 'False'
END
I am getting the following output for this:
Element
'xpath=//*[#id="generalAndIncidents:generalAndIncidentsPanel"]' should
have contained text '['Benutzer', 'Passwort', 'Sendung',
'Transaktionen', 'Notiz']' but its text was.... (and it lists all the
text from my locator)
So, it is basically not checking the words one by one.
Am I doing something wrong here? Is this a bad approach I am trying to do here?
I would be grateful if anyone could provide me some hint on what I should do here instead!
Thank you very much!
You've made one small but crucial mistake - the variable in this line here:
FOR ${label} IN ${text_list_variable}
, should be accessed with #:
FOR ${label} IN #{text_list_variable}
The for-in loops in RF expect 1 or more arguments of the looped over values, and the # expands a list variable to its members.
Eiffel Studio seems to pass through my requirements even if I have them enabled on project settings. And as far as I remember I was able some time to put a break point into the requirements...
I don't understand what I'am missing here, as you can see in my example, the requirement passes through as I have the same condition on the code and it goes into (attached {POWER_DEVICE} a_csv.device as l_dev).
A general rule for inherited assertions is the following:
preconditions can be only relaxed;
postconditions can be only strengthened.
In the particular example the effective precondition is
True
or else
valid_csv (a_csv) and then attached {POWER_DEVICE} a_csv.device
This is reflected by the keywords require at the beginning and require else in the middle of the combined precondition in the flat form of the feature. The expression True is inherited. This is the precondition of the feature in the parent.
A possible solution is to move valid_csv (a_csv) to the parent feature, and redefine valid_csv in the descendant. If valid_csv is common for all calls, but the second test varies across descendants, it might be better to introduce a new feature is_known and have 2 precondition subclauses in the parent:
is_valid_csv: is_valid_csv (a_csv)
is_known_csv: is_known_csv (a_csv)
The implementation of is_known_csv in the class POWER_CSV_PROCESSOR would be
is_known_csv (a_csv: ...)
do
Result := attached {POWER_DEVICE} a_csv.device
end
and the precondition of feature process in POWER_CSV_PROCESSOR would be empty.
The caller would then do something like
if processor.is_known_csv (csv) then
processor.process (csv)
end
I'm customizing the standard "c.vim" syntax file in order to tune the visualisation of my C code.
I would like to distinguish the color of the "called functions" from the one of the "declared functions".
Exemple:
int declared_function()
{
int m;
m = called_function();
return (m)
}
I read in depth the VIM documentation, and millions of forums and google results, but all the solutions I tried didn't work.
To resume, I did this:
I defined a region in a recursive way in order to consider all the code within the braces:
syn region Body start="{" end="}" contains=Body
Then I defined through VIM patterns a general function syntax:
syn match cFunction "\<\h\w*\>\(\s\|\n\)*("me=e-1 contains=cType,cDelimiter,cDefine
I did this because I thought I could combine the two in a "if else" condition in the .vimrc file... but after a whole day of failing tests I need the help of someone, who can tell me if it's possible and how to do it.
Thanks everybody.
You're very close. First, you don't need the recursive definition, but contain all other top-level C syntax elements in it, plus the special group you'll define for called functions:
:syn region Body start="{" end="}" contains=TOP,cFunctionUse
Actually, scratch that, the default $VIMRUNTIME/syntax/c.vim already defines a cBlock syntax group.
Then, define a different syntax group that is contained in the cBlock group.
:syn match cFunctionUse "\<\h\w*\>\(\s\|\n\)*("me=e-1 contained containedin=cBlock contains=cType,cDelimiter,cDefine
Finally, link or define a different highlight group for it, so that it actually looks different:
:hi link cFunctionUse Special
You can put those into ~/.vim/after/syntax/c.vim, so that they'll be added automatically to the default C syntax.
I work in safety critical application development. Recently as a code reviewer I complained against coding style shown below, but couldn't make a strong case against it. So what would be a good argument against such Variable redundancy/duplication, I am looking for cases where this might lead to problems or test cases which might fail, rather than just coding style.
//global data
// global data
int Block1Var;
int Block2Var;
...
//Block1
{
...
Block1Var = someCondition; // someCondition is an logical expression
...
}
//Block2
{
...
Block2Var = Block1Var; // Block2Var is an unconditional copy of Block1Var
...
}
I think a little more context would be helpful perhaps.
You could argue that the value of Block1Var is not guaranteed to stay the
same across concurrent access/modification. This is only valid if Block1Var
ever changes (ie is not only read). I don't know if you are concerned with
multi-threaded applications or not.
Readability is an important issue as well. Future code maintainers
don't want to have to trace around a bunch of trivial assignments.
Depends on what's done with those variables later, but one argument is that it's not future-proof. If, in the future, you change the code such that it changes the value of Block1Var, but Block2Var is used instead (without the additional change) later on, then this will result in erroneous behavior.
If the shown function context reaches a certain length (I'm assuming a lot of detail has been discarded to create the minimal reproducible example for this question), a good next step could be to create a new (sub-)function out of Block 2. This subfunction then should be started assigning Block1Var (-> actual parameter) to Block2Var (-> formal parameter). If there were no other coupling to the rest of the function, one could cut the rest of Block 2 and drop it as a function definition, and would only have to replace the assignment by the subfunction call.
My answer is fairly speculative, but I have seen many cases where this strategy helped me to mark useful points to split a complex function later during the development. Of course, this interpretation only applies to an intermediate stage of development and not to code that is stated to be "ready for release".
I have developed a interpreted programming language. It is strongly based on C. The problem is, I want to add a foreach directive and have no clue how to.
I am using Bison and Flex as the parser and lexer generator.
In your grammar, you'd want an expression that is something like the following:
foreach := foreach ( name in name ) { statements }
When you parse this, you should be able to translate it directly into a while loop in your AST with an additional statement that assigns a variable at the beginning.
This seems to me the simplest way to do it, but will probably have limitations with multiple iterable data-types (e.g. a list vs. an array). In this case, you may want to consider consolidating all iterables so that they have a consistent method to obtain the next element.