Hi,
Thank for your response. I realised after. I passed all variables as a
parameter.
Regards.
2016-12-19 17:07 GMT+01:00 Risto Vaarandi <risto.vaara...@gmail.com>:
> 2016-12-19 14:04 GMT+02:00 Jaren Peich <burkol...@gmail.com>:
> > Hi,
> >
> > Sorry Risto i think i explained wrongly. Sorry for my english again.
> >
> > How can i access and retrieve the values declares in "Rule 1" (assign
> > sentences)(ex. assign %priority (medium);) in the lcall block of code in
> > "Rule 3"?
> >
> > One case:
> > I want to print the value of %priority variable declared in "Rule 1" in
> > "Rule 3"? The variable is created in "Rule 1" with assign sec sentence.
> How
> > can i access?
> >
> > In "Rule 3":
> > For example, in lcall block:
> > print "%priority";\-->Output: prints nothing or %priority. It
> doesn´t
> > print the value assigned in "Rule 1".
> >
> > Also thank you for the explanation of lcall and eval.
>
> ...since in the case of 'lcall' the code has to be a function which is
> compiled only once, you can not access match variables or action list
> variables directly in the code. For example, the statement
>
> print "%priority";
>
> assumes that the %priority variable is substituted with a potentially
> different value before each execution. Unfortunately, that would mean
> that the code itself changes before execution, and therefore it would
> have to be recompiled each time. However, since 'lcall' compiles the
> code just once when the corresponding rule is loaded,
> substitution-based approach can never work. For this reason, variable
> substitution is *never* done inside the Perl code for the 'lcall'
> action. Therefore, in the following statement
> print "%priority"
> "%priority" does not mean the action list variable inside double
> quotes, but is rather interpreted by Perl itself. Since "%priority" is
> just a string for Perl, the above print statement simply prints out
> that string.
>
> In order to allow to pass custom data to the code, it is done with via
> function parameters (remember that 'lcall' only accepts a valid
> function definition for the code). The 'lcall' action has the
> following syntax (quote from the man page):
>
> lcall %<var> [<paramlist>] -> <code>
>
> <paramlist> is an optional list of input parameters which have to be
> separated by whitespace. Inside the function, these parameters can be
> accessed through $_[0] (first parameter), $_[1] (second parameter),
> $_[2] (third parameter), etc. special variables (these variables are
> *not* sec variables, but standard variables of the Perl language).
>
> For example, suppose you have the following rule definition:
>
> type=single
> ptype=substr
> pattern=test
> desc=test
> action=add TEST abc; add TEST def; copy TEST %param1; \
> assign %param2 xyz zyx; \
> lcall %ret %param1 %param2 -> ( sub { print "First: ", $_[0],
> "\n"; } ); \
> lcall %ret %param1 %param2 -> ( sub { print "Second: ", $_[1],
> "\n"; } ); \
> lcall %ret %param2%param1 -> ( sub { print "Third: ", $_[0], "\n";
> } )
>
> In the action field, the 'copy' action sets %param1 variable to the
> following string "abc<NEWLINE>def", while %param2 variable is set to
> "xyz zyx".
>
> The first invocation of 'lcall' will pass the following parameters to
> the precompiled function
> sub { print "First: ", $_[0], "\n"; } :
>
> 1st parameter - "abc<NEWLINE>def"
> 2nd parameter -"xyz zyx"
>
> Note that since newline and space character appear *within* the
> parameter values, they are *not* considered separators between
> parameters. Therefore, the function will print out the following data:
>
> First: abc
> def
>
> The second invocation of 'lcall' will pass the same parameters to the
> function it invokes, but since this time the second input parameter is
> accessed in the function, the output is:
>
> Second: xyz zyx
>
> The third invocation of 'lcall' passes only one parameter to the
> function it invokes, and this parameter is the concatenation of the
> values of %param2 and %param1:
>
> "xyz zyxabc<NEWLINE>def"
>
> Note that these values are concatenated into a *single* parameter,
> since there is no space between %param2 and %param1. (If the space
> *would* be there, the parameters would be *swapped* -- the value of
> %param2 would become the first parameter and %param1 the second inside
> the function.)
>
> For this reason, the third 'lcall' action will print out the following
> data:
> Third: xyz zyxabc
> def
>
> Finally, you might ask the following question -- what value gets
> assigned to the %ret action list variable which gets return values
> from the functions? Since each successful 'print' statement returns 1,
> the %ret variable will be set to 1 in all three cases (provided that
> the functions didn't experience any issues with printing to standard
> output).
>
> I hope this e-mail helped to clarify how the parameters have to be
> provided and how to access them inside the function. If you want to
> refer to the entire parameter list, the @_ notation would have to be
> used (the details are given in the "perlsub" documentation page).
>
> hope this helps,
> risto
>
>
> >
> > Regards. Thank for your help again.
> >
> > 2016-12-19 12:44 GMT+01:00 Risto Vaarandi <risto.vaara...@gmail.com>:
> >>
> >> > Which is the difference between eval and lcall?
> >>
> >> 'eval' will compile the code before *each* execution. This has the
> >> advantage of using match variables and action list variables directly
> >> in the code:
> >>
> >> action=assign %test mystring; eval %o ( print "%test", "\n" )
> >>
> >> For example, the above action list does the following:
> >> 1) action list variable %test is set to mystring;
> >> 2) the action list variable %test is substituted in the Perl code of
> >> 'eval' action, yielding:
> >> print "mystring", "\n"
> >> 3) the code print "mystring", "\n" is compiled
> >> 4) the compiled code is executed
> >>
> >> However, because of step 3 the 'eval' action is *very* expensive when
> >> compared to 'lcall'. With 'lcall', the perl code is just compiled once
> >> when SEC reads in rules from its configuration files, and all the
> >> invocations of 'lcall' execute already compiled code. Therefore, I
> >> would recommend to use 'eval' only when it is going to be executed few
> >> times (e.g., for loading Perl modules at SEC startup).
> >>
> >> hope this helps,
> >> risto
> >
> >
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
