This CMake Doc : https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html tells us that :
$<CONFIG> Configuration name.
and that :
Conditional generator expressions depend on a boolean condition that must be 0 or 1.
$<condition:true_string> Evaluates to true_string if condition is 1. Otherwise evaluates to the empty string.
$<IF:condition,true_string,false_string> New in version 3.8.
Evaluates to true_string if condition is 1. Otherwise evaluates to false_string.
Typically, the condition is a boolean generator expression. For instance,
$<$<CONFIG:Debug>:DEBUG_MODE> expands to DEBUG_MODE when the Debug configuration is used, and otherwise expands to the empty string.
If I understand correctly, in Visual Studio, if I'm switching from Debug to Release this line :
$<$<CONFIG:Debug>:DEBUG_MODE>
Should also expand to DEBUG_MODE, isn't it ? because CONFIG will contain, according to my understanding "Release" and it's a non empty string, thus it will expand to Debug, than this last will make the first generator expression expand to DEBUG_MODE because of this statement in the documentation :
$condition:true_string Evaluates to true_string if condition is 1.
Otherwise evaluates to the empty string.
I know I'm wrong, please help me to understand how it works.
because CONFIG will contain
CONFIG does not contain, it's not a condition, it's a specific Variable query with special rules.
$<CONFIG:cfgs>
1 if config is any one of the entries in cfgs, else 0. [...]
Let's say it works like this:
extract the parts A and B like $<A:B>
if part A is CONFIG
- then do stuff related to CONFIG
if part A is, for example, STREQUAL
- then do stuff on B related to STREQUAL.
for each case ...
otherwise it's a condition, so if it's 1, then return B, otherwise empty string.
Related
The problem here is that I do not understand well the difference between statements and blocks in control flow.
Looking the ternary operator I can use it to assign a variable. But this is an operator, so it is like applying a function--isn't it?
> my $variable = True ?? 34 !! 42;
34
since in the raku documentation says:
if documentation
if
To conditionally run a block of code, use an if followed by a
condition. The condition, an expression, will be evaluated immediately
after the statement before the if finishes. The block attached to the
condition will only be evaluated if the condition means True when
coerced to Bool. Unlike some languages the condition does not have to
be parenthesized, instead the { and } around the block are mandatory:
do documentation
do
The simplest way to run a block where it cannot be a stand-alone statement is by writing do before it:
so this should work in both cases:
> my $variable = do {34};
34
> my $variable = if True {34;} else {43;}
===SORRY!===
Word 'if' interpreted as a listop; please use 'do if' to introduce the statement control word
------> my $variable = if⏏ True {34;} else {43;}
Unexpected block in infix position (two terms in a row)
------> my $variable = if True⏏ {34;} else {43;}
as said in the error I need to add the do:
> my $variable = do if True {34;} else {43;}
34
So the if really does not run the block...or what is the real problem here?
TL;DR: The actual difference is between statement and expression, not statement and block. do is a statement prefix that creates expressions.
if actually creates a statement (anything that is run in Raku is), however, what it's not is an expression. do is a statement prefix, and what it does is turn statements into expressions.
However, if is not really a first-class function that you can assign to a variable or handle around. Whenever you find pieces of syntax such as that one (or for, for instance), you need to prefix them with do to "expressionify" them.
say &say.^name;# OUTPUT: «Sub» say &do.^name; # OUTPUT: «===SORRY!=== Error while compiling <tmp>Undeclared routine:...
say &if.^name; # OUTPUT: «===SORRY!=== Error while compiling <tmp>Undeclared routine: if used at line 1»
So if, by itself, does not create a block, it does not create an expression, it simply creates a statement. You need to precede it with do if you want it to actually turn it into a expression. It does run the block that's behind it, however.
Let's go back to the original question, statements and blocks. Blocks are objects, first-class citizens. You can use them, apply them, pass them around.
my &ifs = { if $_ {34} else {43}};
ifs(True).say; # OUTPUT: «34»
Statements are throwaway blocks you simply run. In some cases, they are also expressions: they yield a result which, then, you can assign.
my &ifs = { if $_ {34} else {43}};
my $result = ifs(True).say; # OUTPUT: «34»
say $result; # OUTPUT: «True»
The ifs(True).say statement prints to output, it also produces a result that can be assigned. All three lines are also statements, and as a matter of fact, expressions too.
Some control structures, however, do not create expressions.
Some others do; for creates a expression; while does not.
if is an example of this. They don't produce a result. You use them for the side effects: running a statement (if true) or another (if not). You might turn them into a block, as above, and pass them around. Or you can just precede them with do and make them produce a throwaway result, which you can then use.
So it will very much depend on your actual use case. You can surround the if statement with curly braces and create a block; or you can simply use the result creating an expression. Or you might want to use it just for the side effects, doing nothing.
I'd like to make a string substitution in a for block using a named capture. I've expected to get the numbers 1,2,3 as output. But it is Nil for the first run, and then 1 and 2 for the 2nd and 3rd run. How do I use the .subst correctly in the loop construct? I see the same behavior when using a map construct instead the for loop. It does work as expected, if I replace with a fixed string value.
for <a1 b2 c3> -> $var {
say $var;
say $var.subst(/.$<nr>=(\d)/, $<nr>); #.subst(/.$<nr>=(\d)/, 'X'); #OK
}
#`[
This is Rakudo version 2019.11 built on MoarVM version 2019.11
Output:
a1
Use of Nil in string context
in block at test3.pl6 line 3
b2
1
c3
2
]
TL;DR Defer evaluation of $<nr> until after evaluation of the regex. #JoKing++ suggests one way. Another is to just wrap the replacement with braces ({$<nr>}).
What happens when your original code calls subst
Before Raku attempts to call the subst routine, it puts together a list of arguments to pass to it.
There are two values. The first is a regex. It does not run. The second value is $<nr>. It evaluates to Nil because, at the start of a program, the current match object variable is bound to something that claims its value is Nil and any attempt to access the value of a key within it -- $<nr> -- also returns Nil. So things have already gone wrong at this point, before subst ever runs.
Once Raku has assembled this list of arguments, it attempts to call subst. It succeeds, and subst runs.
To get the next match, subst runs the regex. This updates the current match object variable $/. But it's too late to make any difference to the substitution value that has already been passed to subst.
With match in hand, subst next looks at the substitution argument. It finds it's Nil and acts accordingly.
For the second call of subst, $<nr> has taken on the value from the first call of subst. And so on.
Two ways to defer evaluation of $<nr>
#JoKing suggests considering use of S///. This construct evaluates the regex (between the first pair of /s) first, then the replacement (between the last pair of /s). (The same principle applies if you use other valid S syntaxes like S[...] = ....)
If you use subst, then, as explained in the previous section, Raku puts together the argument list for it before calling it. It finds a regex (which it does not run) and a closure (which it does not run either). It then attempts to call subst with those arguments and succeeds in doing so.
Next, subst starts running. It has received code for both the match (a regex) and the substitution (a closure).
It runs the regex as the matching operation. If the regex returns a match then subst runs the closure and uses the value it returns as the substitution.
Thus, because we switched from passing $<nr> as a naked value, which meant it got frozen into Nil, to passing it wrapped in a closure, which deferred its evaluation until $/ had been set to a match with a populated <nr> entry, we solved the problem.
Note that this only works because whoever designed/implemented subst was smart/nice enough to allow both the match and substitution arguments to be forms of Code (a regex for the match and ordinary closure for the substitution) if a user wants that. It then runs the match first and only then runs the substitution closure if it's been passed one, using the result of that latter call as the final substitution. Similarly, S/// works because that has been designed to only evaluate the replacement after it's first evaluated the substitution.
In Selenium I have written a xpath and both of them retrieves the same result.
//a[#role='tab'][text()=' Assets']
//a[#role='tab' and text()=' Assets']
Does both of them have the same meaning?
In most cases a[b][c] has exactly the same effect as a[b and c]. There are two exceptions to be aware of:
They are not equivalent if either predicate is numeric, or has a dependency on position() or last() (I call these positional predicates). For example a[#x][1] selects the first a element that has an #x attribute, while a[1][#x] selects the first a element provided it has an #x attribute (and selects nothing otherwise). By contrast a[1 and #x] converts the integer 1 to the boolean true(), so it just means a[#x].
There may be differences in behaviour if evaluation of b or c fails with a dynamic error. The precise rules here depend on which version of XPath you are using, and to be honest the rules leave implementations some leeway, but you need to exercise care if you want to be sure that in the event of b being false, c is not evaluated. (This hardly matters in XPath 1.0 because very few expressions throw dynamic errors.)
When you add Square Brackets ([]) to XPath you are adding a condition, so
first row adding 2 conditions
Which produce similar results as adding condition with and
Normally you don't use first row, because it less readable,
Mainly because this syntax represent in other languages a Matrix
// return a random m-by-n matrix with values between 0 and 1
public static double[][] random(int m, int n) {
See tutorial:
5 XPaths with predicates
A predicate is an expression that can be true or false
It is appended within [...] to a given location path and will refine results
More than one predicate can be appended to and within (!) a location path
The first one is a predicate, which means it checks if a[#role='tab'] is true then it proceeds to [text()=' Assets']
The second one is a just using an and operator so it validates both are true.
tl;dr
When I use my variable created in Regular Expression Extractor I cannot use it in Random Variable as Maximum Value
Long description:
My test structure:
I have variable my_test what is crated in Regular Expression Extractor
request: GET //echo.getpostman.com/get?test=123
regex:
Then I want it use as Maximum Value in Regular Expression Extractor
So finally I can make request:
//echo.getpostman.com/get?test=${rand}
Unfortunately I get error from Random Variable
2016/10/07 07:52:41 ERROR - jmeter.config.RandomVariableConfig: maximum(${my_test}) must be > minimum1)
Why my_test is not evaluated?
I have tried ${__javaScript(parseInt('${my_test}'))} but it looks like it is evaluated before my variable initialization
2016/10/07 08:06:01 ERROR - jmeter.config.RandomVariableConfig: maximum(NaN) must be > minimum1)
If I initialize this variable in Test Plan in User Defined Variables value from that setting will be used - not updated by regex.
I know that I can do //echo.getpostman.com/get?test=${__Random(0,${my_test})}
I'm just curious how pass my variable as value for Maximum Value in Regular Expression Extractor.
Random Variable is a Config Element and it will be executed first before any other components get executed first.
4.9 Execution order
Configuration elements
Pre-Processors
Timers
Sampler
Post-Processors (unless SampleResult is null)
Assertions (unless SampleResult is null)
Listeners (unless SampleResult is null)
If two or more Config elements present in the Test Plan, then they will be executed in the order they appear in the Test Plan.
Check the execution order and Scope here:
Refer 4.9 7 4.10 here Execution Order and Scope Rules
So, first Random Variable is evaluated first and then Sampler and then regular expression extractor.
When you used User Defined Variables, which is another Config Element, and probably you put it before Random Variable, so it evaluated the expression as you already defined the value for "my_test". But it won't override the value you captured in Regular Expression Extractor.
To solve your problem (one probable solution):
you can use different thread groups. In first thread group, you capture the value and in second thread group, you use the value.
Run Thread Groups consecutively.
Use BeanShell Assertion to capture the value by setProperty. (in first thread group)
Use value using __property() (in thread group)
https://www.blazemeter.com/blog/knit-one-pearl-two-how-use-variables-different-thread-groups
It seems that Random Variable element does not evaluate variables, maybe it worth creating an issue in JMeter Issue Tracker
As a workaround you can substitute it with __Random() function directly where required like:
${__Random(1,${my_test},)} - if you need the value right away, directly in you URL:
//echo.getpostman.com/get?test=${__Random(1,${my_test},)}
${__Random(1,${my_test},rand)} - if if you need to store the value into ${rand} variable as well
See:
Using JMeter Functions article for extended information on this and others JMeter Functions.
Function Helper Dialog - an utility helping to generate correct function syntax.
I think it's valid for me to comment on a problem I had, I set the random variable and it didn't work at all, I did everything I could to try to solve it.
In the end my problem was a space at the beginning of the variable.
One possibility is you can use a Beanshell Postprocessor to write the RegEx value to the variable name.
After that you can use it as ${variable_name}
NB: Beanshell function vars.get can be used for getting regex value and vars.put can be used for putting it into your variable.
The first image below is the parent workflow and the image below that is the child workflow. In the child workflow I check if a singular value I provide is in the list separated by commas I also provide. I use a Regex matcher along with an if node to do this. The problem is the Regex matcher continues to execute for all matches although I want it to stop checking # 2016/05/13 09:08:30, when the expression evaluates to true (the word 'Contract' is present in 'Contract,VMS,Payroll'). I want the Regex matcher to stop and then output isTrue boolean to the variable bar so the parent workflow gets a 'true' instead of the false which it gets now. (which you can see happens in the last activity entry 2016/05/13 09:08:30 where Value is false (since it gets the LAST updated value) for the child workflow).
Hmmm..... There isn't a way to break out of that loop but you should be able to use Regex Match One instead of the loop version as you're actually only interested in determining whether a given pattern matches rather than needing to iterate over each match in order to process it further.
Yes or if its really just s simple string match, use the If Node with expression 'Value like "matchexpression" '