I'm trying to write a config class for a SV testbench and wanted to decide randomization of rand fields in my transaction class, directly from the command line. I thought I could declare a static variable "mode" in my config class which takes 1 or 0 and assign this to the rand_mode (rand_mode(mode)) task called in my transaction class. Is this possible? And if so, should I declare my static variable in the config class as bit(as it needs only 1 or 0) or as boolean?
There is no boolean type in SystemVerilog, you can use a bit. And there is no need to make it static.
Also, consider using the UVM config db, even if your test is not written in UVM. It has built-in command line settings for configuration values.
Related
I have environmental variable called ENV, which holds the DEV,QA OR PROD region as value. When the server.xml loaded it includes the corresponding db configuration using this variable. For ex: db-config-${env.GAH_ENV}.xml
I would like to pass the same value to the batch job xml as a job parameter or properties to any of the class. How Can I do that.
below code snippet not working
<property name="environment" value="${env.GAH_ENV}"/>
The short answer is that using a batch property may not be a good solution and you might consider something else like MicroProfile's #ConfigProperty.
The reason is there's not a built-in way to access environmental variables through JSL substitution. There is also not a convenient way for one artifact to set a property value to be used by a second artifact running later within the job execution.
In the special case that you are starting the job from within the same JVM it will execute, of course, you could pass the env var value as a job parameter.
But in the general case, if you can change the Java code and you don't really need a batch property I would use a MicroProfile Config property instead, injected via #Inject #ConfigProperty.
By doing so you lose the batch-specific substitution precedence, including the override available via job parameters passed with the submit/start. You also give up the ability to use this property in other JSL substitutions (to "compose" its value into other batch properties via other substitutions).
But you at least get a property with its own various levels of precedence/override (e.g. server config, env var, microprofile-config.properties), which is more flexible than just always reading the env var via System.getenv( ).
This is certainly an area to consider for the next version of the (now-Jakarta) Batch spec.
I want to control read access to an Itcl public variable. I can do this for write access using something such as:
package require Itcl
itcl::class base_model_lib {
public variable filename ""
}
itcl::configbody base_model_lib::filename {
puts "in filename write"
dict set d_model filename $filename
}
The configbody defines what happens when config is called: $obj configure -filename foo.txt. But how do I control what happens during the read? Imagine that I want to do more than just look up a value during the read.
I would like to stay using the standard Itcl pattern of using cget/configure to expose these to the user.
So that is my question. However, let me describe what I really want to do and you tell me if I should do something completely different :)
I like python classes. I like that I can create a variable and read/write to it from outside the instance. Later, when I want to get fancy, I'll create methods (using #property and #property.setter) to customize the read/write without the user seeing an API change. I'm trying to do the same thing here.
My sample code also suggests something else I want to do. Actually, the filename is stored internally in a dictionary. i don't want to expose that entire dictionary to the user, but I do want them to be able to change values inside that dict. So, really 'filename' is just a stub. I don't want a public variable called that. I instead want to use cget and configure to read and write a "thing", which I may chose to make a simple public variable or may wish to define a procedure for looking it up.
PS: I'm sure I could create a method which took either one or two arguments. If one, its a read and two its a write. I assumed that wasn't the way to go as I don't think you could use the cget/configure method.
All Itcl variables are mapped to Tcl variables in a namespace whose name is difficult to guess. This means that you can get a callback whenever you read a variable (it happens immediately before the variable is actually read) via Tcl's standard tracing mechanism; all you need to do is to create the trace in the constructor. This requires the use of itcl::scope and is best done with itcl::code $this so that we can make the callback be a private method:
package require Itcl
itcl::class base_model_lib {
public variable filename ""
constructor {} {
trace add variable [itcl::scope filename] read [itcl::code $this readcallback]
}
private method readcallback {args} { # You can ignore the arguments here
puts "about to read the -filename"
set filename "abc.[expr rand()]"
}
}
All itcl::configbody does is effectively the equivalent for variable write traces, which are a bit more common, though we'd usually prefer you to set the trace directly these days as that's a more general mechanism. Demonstrating after running the above script:
% base_model_lib foo
foo
% foo configure
about to read the -filename
{-filename {} abc.0.8870089169996832}
% foo configure -filename
about to read the -filename
-filename {} abc.0.9588680136757288
% foo cget -filename
about to read the -filename
abc.0.694705847974264
As you can see, we're controlling exactly what is read via the standard mechanism (in this case, some randomly varying gibberish, but you can do better than that).
While modifying an existing program's CASE statement, I had to add a second block where some logic is repeated to set NetWeaver portal settings. This is done by setting values in a local variable, then assigning that variable to a Changing parameter. I copied over the code and did a Pretty Print, expecting to compiler to complain about the unknown variable. To my surprise however, this code actually compiles just fine:
CASE i_actionid.
WHEN 'DOMIGO'.
DATA: ls_portal_actions TYPE powl_follow_up_sty.
CLEAR ls_portal_actions.
ls_portal_actions-bo_system = 'SAP_ECC_Common'.
" [...]
c_portal_actions = ls_portal_actions.
WHEN 'EBELN'.
ls_portal_actions-bo_system = 'SAP_ECC_Common'.
" [...]
C_PORTAL_ACTIONS = ls_portal_actions.
ENDCASE.
As I have seen in every other programming language, the DATA: declaration in the first WHEN statement should be encapsulated and available only inside that switch block. Does SAP ignore this encapsulation to make that value available in the entire CASE statement? Is this documented anywhere?
Note that this code compiles just fine and double-clicking the local variable in the second switch takes me to the data declaration in the first. I have however not been able to test that this code executes properly as our testing environment is down.
In short you cannot do this. You will have the following scopes in an abap program within which to declare variables (from local to global):
Form routine: all variables between FORM and ENDFORM
Method: all variables between METHOD and ENDMETHOD
Class - all variables between CLASS and ENDCLASS but only in the CLASS DEFINITION section
Function module: all variables between FUNCTION and ENDFUNCTION
Program/global - anything not in one of the above is global in the current program including variables in PBO and PAI modules
Having the ability to define variables locally in a for loop or if is really useful but unfortunately not possible in ABAP. The closest you will come to publicly available documentation on this is on help.sap.com: Local Data in the Subroutine
As for the compile process do not assume that ABAP will optimize out any variables you do not use it won't, use the code inspector to find and remove them yourself. Since ABAP works the way it does I personally define all my variables at the start of a modularization unit and not inline with other code and have gone so far as to modify the pretty printer to move any inline definitions to the top of the current scope.
Your assumption that a CASE statement defines its own scope of variables in ABAP is simply wrong (and would be wrong for a number of other programming languages as well). It's a bad idea to litter your code with variable declarations because that makes it awfully hard to read and to maintain, but it is possible. The DATA statements - as well as many other declarative statements - are only evaluated at compile time and are completely ignored at runtime. You can find more information about the scopes in the online documentation.
The inline variable declarations are now possible with the newest version of SAP Netweaver. Here is the link to the documentation DATA - inline declaration. Here are also some guidelines of a good and bad usage of this new feature
Here is a quote from this site:
A declaration expression with the declaration operator DATA declares a variable var used as an operand in the current writer position. The declared variable is visible statically in the program from DATA(var) and is valid in the current context. The declaration is made when the program is compiled, regardless of whether the statement is actually executed.
Personally have not had time to check it out yet, because of lack of access to such system.
I would like to declare some "user-defined compiler-constants" to keep my specification files as "constant" as possible. This is something common in C++, e.g. :
// misc/config.hh
namespace misc
{
typedef std::shared_ptr<A> A_ptr;
namespace arch = ibmpc;
}
// misc/code.hh
#include "misc/config.hh"
namespace misc
{
void function p(A_ptr a);
}
Which would be in Ada :
-- misc.ads
package Misc is
use Types; ----> forbidden !
procedure P(A : A_Access);
end Misc;
-- misc-types.ads
package Misc.Types is
type A_Access is A'Access;
end Misc.Types;
Of course this does not work since use is a context keyword...hence my question : how is it possible to do something with the same results in Ada ?
I think this is a reasonable mapping from your C++ original to Ada:
To start with, corresponding more-or-less, I think, to your namespace misc, in file misc.ads,
package Misc is
end Misc;
Then, corresponding to config.hh, in file misc-config.ads,
package Misc.Config is
type A is (For_Example, An_Enumeration);
type A_Access is access A;
end Misc.Config;
(which could, of course, also reference types in Misc). Then, corresponding to code.hh, in file misc-code.ads,
with Misc.Config;
package Misc.Code is
use Config;
procedure P (A : A_Access);
end Misc.Code;
Personally I wouldn’t use Config;, at any rate in specs - it can make it difficult to work out where something is defined. Note, you can say use Config; or use Misc.Config; where shown, because you’re in a child of Misc; in the context clause, which is also OK, you would have to use Misc.Config;.
Ok, while I see what you're trying to do you're going about it wrong.
The problem you have with the given sniplets is this: circular dependency.
Now Ada has a great way of managing circular dependency by making it non-circular (in a sense) through it's use of specs and bodies. As the two are discrete, we can have two sets of spec/body files where the body references the other's spec precisely because the specs are publicly visible.
As an example, admittedly ridiculous; let's use fountain-pens and ink-cartridges.
With Cartridge;
Package Pen is
Subtype Model_Number is Positive Range 1000..3304;
Type Fountain_pen is private;
-- Pen procedures
private
Type Fountain_pen is Record
Model : Model_Number;
Ink : Cartridge.Ink_Cartridge;
end record;
end Pen;
and
With Pen;
Package Cartridge is
Type Ink_Cartridge is private;
-- Ink procedures
private
Type Ink_Cartridge is record
Color : Integer; -- I'm being lazy.
This_Pen : Pen.Fountain_pen;
end record;
end Cartridge;
and
Package Body Pen is
--- Pen Stuff
end Pen;
Package Body Cartridge is
-- Ink stuff
end Cartridge;
(Not compiled.)
I forget how to create a component of a circularly-nested type though... Anyway, you should get the general idea there. But what you're wanting is fundamentally different than mutually dependent types; what you want is some sort of container for your constants.
I would recommend using child packages. Something like Misc and Misc.Constants; where you place your base-types into Misc, and the constants into Misc.Constants. If your types are dependent on your constants you might make a separate child package for them Misc.Types and use the mutual withing as shown above.
You could put the child package spec inside the parent package spec, like this:
package Misc is
package Types is
type A is private;
type A_Access is access A;
-- other stuff
end Types;
procedure P (A : Types.A_Access);
end Misc;
you can even use Types; after the declaration of Misc.Types.
There is a "NameAndType" structure in the constants pool in .class file.
It is used for dynamic binding.
All methods that class can "export" described as "signature + return type".
Like
"getVector()Ljava/util/Vector;"
That breakes my code when return type of the method in some .jar is changed, even if new type is narrower.
i.e:
I have the following code:
List l = some.getList();
External .jar contains:
public List getList()
Than external jar changes method signature to
public ArrayList getList().
And my code dies in run-time with NoSuchMethodException, because it can't find
getList()Ljava/util/List;
So, I have to recompile my code.
I do not have to change it. Just recompile absolutely the same code!
That also gives ability to have two methods with one signature, but different return types! Compiler would not accept it, but it is possible to do it via direct opcoding.
My questions is why?
Why they did it?
I have only one idea: to prevent sophisticated type checking in the runtime.
You need to look up to the hierarchy and check if there is a parent with List interface.
It takes time, and only compiler has it. JVM does not.
Am I right?
thanks.
One reason may be because method overloading (as opposed to overriding) is determined at compile time. Consider the following methods:
public void doSomething(List util) {}
public void doSomething(ArrayList util) {}
And consider code:
doSomething(getList());
If Java allowed the return type to change and did not throw an exception, the method called would still be doSomething(List) until you recompiled - then it would be doSomething(ArrayList). Which would mean that working code would change behavior just for having recompiled it.