what would be the purpose of Automatic Variable in ILOG Jrules? - business-rules

In the rule studio , while verbalizing a BOM object , there is checkbox called "Generate Automatic Variable" , what would be its purpose ? Is it a global variable ?

Automatic variables are there for you to access the working memory object directly via the verbalization.
It based on the usage you want to use :)
there is no better way than an other.
if you want to populate the working memory and let the engine deal with the manipulation then you can use automatic variables
If you want to control everything then use rule variable (pre conditions - starting with "definitions")
It can depend on how business users want to create/author rules, as well
The doc says:
Because objects in the working memory cannot be named or
verbalized, you must bind them to rule variables or automatic variables
by defining a pattern in the definitions of the rule artifact to manipulate
them
– At run time the rule engine cycles through all the objects in working memory to
find objects that match the definition of the rule variable
– The rule engine creates a separate rule instance for every match, which works
on the object that caused that particular rule instance to be created
• You can also use rule variables simply to enhance the way your rules
are written
– For example to reduce the length of your conditions or your actions when you
author rules, or to define a constant used in the rule
I have been using JRules for years and it all depends on the design you want to implement.
As a JRules instructor, I would say: Pick up what you prefer but personnally I don't use them. Except quick POCs.
Hope it helps

It is more like a global variable which can be accessed anywhere in the rule project.
Please Refer to the documentation especially the section about the setup of automatic variables

Related

Terraform share common variables for modules

We have a common variables in our infrastructure on AWS, planned to be used by several modules. For example subnet ids, vpc id and so on.
To avoid duplication those variable in each module in *.tfvars files. Is that possible make them available from any terraform modules? While modules itself can be isolated from each other.
I think about kind of core module, which can be imported where that common variables needs. But in doubts that module is a right way to do that, as modules intended to have only resources in them, but we need expose only variables. Is it right way to use modules to share variables? Or how you guys cope with this problem? Think it's common or it's bad approach in terraform?)
Thanks.
If you have a set of expressions (including hard-coded literal values) that you want to reuse then it is valid to write a module which only contains input variable declarations, local values, and output values as a way to model that.
The simplest form of this would be a module that only contains output blocks whose values are hard-coded literal values, like this:
output "example" {
value = "result"
}
The official module hashicorp/subnets/cidr is an example of that: it doesn't declare any resources of its own, and instead it just encapsulates some logic for calculating a set of subnets based on some input variables.
This is a special case of Data-only Modules where the data comes from inside the module itself, rather than from data sources. A nice thing about modelling shared data in this way is that if you later decide to calculate those results automatically based on data sources then you'll be able to do so, while keeping the details encapsulated. For example, if you define a module which takes an environment name as an input variable and returns derived settings about that environment, the module could contain local logic to calculate those results today but could later determine some of those settings by fetching them from a prescribed remote location, such as AWS SSM Parameter store, if the need arises.

Automatically group member functions based on constness

Can doxygen automatically create groups like "Accessors" and "Modifiers", i.e. group member functions based on const-ness? If not, are these groups common enough that one should consider spending the effort to create them manually?

How to make an old C codebase with many globals reentrant

I'm working with a large, old C codebase (an interpreter) that uses global variables a great deal, with the result that I cannot have two instances of it at once. Is there a straightforward (ideally automated) approach to convert this code to something reentrant? i.e. some refactor tool that would make all globals part of a struct and prepend the pointer to all variables?
Could I convert to C++ and wrap the entire thing in a class definition?
I would recommend to convert your project into C++11 project and change all your static vars into threadlocal.
This can be up to several days of work depending on the size of your project. In certain cases this will work.
I'm not aware of any "ready made" solution for this type of problem.
As a general rule, global variables are going to make it hard to make the code reentrant.
If you can remove all the global variables [simply delete the globals and see where you get compiler errors]. Replace the globals with a structure, and then use a structure per instance that is passed along, you'd be pretty much done (as long as the state of the interpreter instances is independent, and the instances don't need to know about each other). [Of course, you may need to have more than a single structure to solve the problem, but your global variables should be possible to "stick in a structure"].
Of course, making the structure and the code go together as a C++ class (which may have smaller classes as part of the solution) would be the "next step", but it's not entirely straight forward to do this, if you are not familiar with C++ and class designs.
Are you trying to make it reentrant in order to be able to make it multi-thread, and divide the work between threads?
If so, I would consider making it multi process, instead of multy-thread,
What I usually do with interpreters is go straight to a class with instance vars rather than globals. Not sure what you are interpreting, but it could be possible to pass in a file path or string container that the class interprets with an internal thread, so encapsulating the entire interpretation run.
It is possible to wrap the whole thing in a class definition, but it will not work for code that takes addresses of functions and passes them to C code. Also, converting a large legacy code base to be compilable by a C++ compiler is tedious enough that it probably outweighs the effort of removing the global variables by hand.
Barring that one, you have two options:
Since you need reentrancy to implement threading, it might be easiest to declare all global variables thread-local. If you have a C compiler that supports thread-locals, this is typically as easy as slapping a __thread (or other compiler-specific keyword) before every declaration. Then you create a new interpreter simply by creating a new thread and initializing the interpreter in the normal way.
If you cannot use __thread or equivalent, then you have to do a bit more footwork. You need to place all global variables in a structure, and replace every access to global variable foo with get_ctx()->foo. This is tedious, but straightforward. Once you are done, get_ctx() can allocate and return a thread-local interpreter state, using an API of your choosing.
A program transformation tool that can handle the C language would be able to automate such changes.
It needs to be able to resolve each symbol to its declaration, and preprocessor conditionals are likely to be trouble. I'd name one, but SO zealots object when I do that.
Your solution of a struct containing the globals is the right idea; you need rewrite that replaces each global declaration with a slot member, and each access to a global with access to the corresponding struct member.
The remaining question is, where does the struct pointer come from? One answer is a global variable that is multiplexed when threads are switched; a better answer if available under your OS is the get the struct pointer from thread local variables.

How can I see all variables available inside a Velocity Template?

Is it possible to display all variables available inside a Velocity Template?
Let's say 1 developer pass 2 values to template: $headline and $body. Another developer has to deal with those 2 variables. How would he know names of those variables?
Right now we use 3 solutions:
we simply say what variables are present on templates
we agreed with all developers that all data we pass to template should be included into 1 map ($data)
developer that pass variables to templates has to update template as well and describe all the fields available on it.
I'm looking for way to do this correctly. Right now I'm not really satisfied with all approaches, but 2-nd looks like most preferable.
The short answer is:
$context.keys
The variables and "tools" are accessed by the templates via the velocity "context". If the context tool is available, you can request the list of variables via $context.keys. If not, you need to add the tool ContextTool to the context. How this is done depends on your application.
Although it's technically possible to list all keys in the context, I'm not sure it's also good practice in the situation you describe.

Use of global variables in simulation code [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Are global variables bad?
I am writing a simulation code making use of material and energy specific data. This data is stored in global arrays, because once uploaded, they are used during the simulation and should be accessible by most of the functions.
I read everywhere that it is not good practice to use global variables.
Could someone explain me or point me to material on the web explaining how I could avoid using global arrays in simulation application coding while massive data arrays need to be used. I try to code in C++ and make use as much as possible of object oriented features.
Thanks in advance for your help.
You are right about the fact that, using globals are not recommended. You can declare those unrelated golbals inside a namespace,
//Globals.h
namespace Globals
{
extern int a[100];
extern double d;
}
and define them in a .cpp file.
//Globals.cpp
int Globals::a[100] = { ... };
double Globals::d = 3.14;
Now use them as Globals::a, Globals::d etc. My answer is in code management perspective.
Yes you are right, global variables are not good.
This is a useful link which explains why global variables are bad and how to avoid them.
http://c2.com/cgi/wiki?GlobalVariablesAreBad
EDIT:
#sergio's post also points to the same link, you can ignore this answer
Could someone explain me or point me to material on the web explaining how I could avoid using global arrays in simulation application coding while massive data arrays need to be used.
The same way you avoid globals in general: by using locals instead. The natural way to get data into a function is to pass it as a parameter. This is not expensive, especially if you pass by reference where appropriate.
Have a look at this article about global variables. This is an excerpt:
Why Global Variables Should Be Avoided When Unnecessary
Non-locality -- Source code is easiest to understand when the scope of its individual elements are limited. Global variables can be read or modified by any part of the program, making it difficult to remember or reason about every possible use.
No Access Control or Constraint Checking -- A global variable can be get or set by any part of the program, and any rules regarding its use can be easily broken or forgotten. (In other words, get/set accessors are generally preferable over direct data access, and this is even more so for global data.) By extension, the lack of access control greatly hinders achieving security in situations where you may wish to run untrusted code (such as working with 3rd party plugins).
Implicit coupling -- A program with many global variables often has tight couplings between some of those variables, and couplings between variables and functions. Grouping coupled items into cohesive units usually leads to better programs.
Concurrency issues -- if globals can be accessed by multiple threads of execution, synchronization is necessary (and too-often neglected). When dynamically linking modules with globals, the composed system might not be thread-safe even if the two independent modules tested in dozens of different contexts were safe.
Namespace pollution -- Global names are available everywhere. You may unknowingly end up using a global when you think you are using a local (by misspelling or forgetting to declare the local) or vice versa. Also, if you ever have to link together modules that have the same global variable names, if you are lucky, you will get linking errors. If you are unlucky, the linker will simply treat all uses of the same name as the same object.
Memory allocation issues -- Some environments have memory allocation schemes that make allocation of globals tricky. This is especially true in languages where "constructors" have side-effects other than allocation (because, in that case, you can express unsafe situations where two globals mutually depend on one another). Also, when dynamically linking modules, it can be unclear whether different libraries have their own instances of globals or whether the globals are shared.
Testing and Confinement - source that utilizes globals is somewhat more difficult to test because one cannot readily set up a 'clean' environment between runs. More generally, source that utilizes global services of any sort (e.g. reading and writing files or databases) that aren't explicitly provided to that source is difficult to test for the same reason. For communicating systems, the ability to test system invariants may require running more than one 'copy' of a system simultaneously, which is greatly hindered by any use of shared services - including global memory - that are not provided for sharing as part of the test.
It also discusses several alternatives. Possibly in your case, you could consider:
hiding your globals (e.g., private static variables);
stateful procedures: setter and getter functions allowing access to the arrays while also "masking" it;
the singleton pattern.
EDIT:
I understand that a part of the development community are against the use of the singleton pattern. I fully respect this opinion. Anyway, in the context of the present discussion, the singleton offers several advantages over the raw use of globals:
improved access control;
opportunity for synchronization;
ability to abstract away the implementation.
In this respect, it is not better from a setter/getter set of functions, but still, not worse. I leave to the OP the hard task of choosing what to do with his own code. (BTW, the article discusses more approaches, like Context Objects, DependencyInjection, etc).
Introducing global state into your code can make it difficult to do things in a multi-threaded way.
I would also argue it can make the intent of your code more difficult to follow. If you pass all of the arguments to a function as parameters at least it's clear what data the function has access to, and what has the potential of changing. The use of global variables doesn't give someone reading the code this chance...
It's also not generally true that using global variables is in any way faster. If you have large objects that you need to pass to functions, pass these arguments via references and there won't be any issues with copying.
Without knowing more about your setup, it's difficult to make any recommendations, but if you have a large amount of data that needs to be passed around to a series of routines I would be tempted to put it all in a struct, and to pass that struct by reference:
struct my_data_type
{
double some_data;
double some_other_data;
std::vector<double> some_coefficients;
std::vector<double> some_other_coefficients;
std::string some_name;
std::string some_other_name;
// add more members as necessary...
};
void foo(my_data_type &data)
{
// there's no big overhead passing data by reference
}
If you only need to access the data in a read-only fashion, it's best to pass as a const reference:
void foo(my_data_type const&data)
{
// again, efficient, but ensures that data can't be modified
}
EDIT: In answer to your comment, I'm not talking about a "global" structure. You would need to declare a local struct variable, read the data from your file into the struct and then pass it by reference to any functions that need to be called:
int main()
{
// a local struct to encapsulate the file data
my_data_type file_data;
// read the data from your file into file_data
// the struct containing the data is passed by reference
foo(file_data);
return 0;
}