I've written a module that can be displayed on several places on the same place. Depending on the module position the executed query differs a bit. But how to find out the module position that calls the script?
Related
I have multiple boards which were having different screen sizes(4",7",12" etc...). I need this info at multiple places in the Linux Kernel during boot time. We can know the device screen size by reading values on two input lines. I don't want to read every time these lines whenever I want to know the device screen size. I want to read these lines once at the beginning(maybe in the board file) and store it in a global variable. Check this global variable value where ever I need the screen size. Can anyone suggest where I can declare this global variable or any better way for this?
So you've given some thought to your problem and you think a "global" variable in the Linux kernel is the fastest/best solution. Where a "global" variable is a variable that one module defines and initializes and other modules can also read and modify it. You can do that by exporting the symbol with the EXPORT_SYMBOL macro.
As an example, look at this file on lines 54 and 55 the symbol drm_debug is declared as an unsigned int and exported for other driver modules to use. The other modules need to be informed about that symbol's existance before they can use it. In this case, that happens in this header file on line 781. So when another file or module wants to use that symbol, that source file includes the header, and then it just uses the variable as if it were declared in that file. If you don't want to create a header file for your "personal" global variables, you can just add that "extern" as a 1-liner to your global scope declarations for that source code file, and it will have the same effect.
In addition to exporting variables, you can also export functions in the same fashion. If you grep for "EXPORT_SYMBOL" in your kernel most of the hits are going to be functions. When you pass around a variable there is the chance that one module might change it at an inopportune moment when another module might be reading it causing undesired outcomes. I like to think of the function as a "read only" version of a variable, so only one module can change it, but everyone else can see it. Having one module being "responsible" for reading and interpreting the GPIO and then sharing that information with other modules to me seems to fit better with the exported function than with the exported variable.
Lastly, whenever you start sharing symbols in the kernel, you should give thought to the name of the global variable you choose. For example, don't take something that's already taken or likely to be taken.
I need to generate Poisson arrival of traffic and thus need to set the start times of applications in clients accordingly. For this I need two things:
1. access parameters of different modules and use them as input for defining a parameter of another module
2. use a for loop to define parameters of modules
For e.g. - the example below demonstrates what I am trying to do.
I have 100 clients and each client has 20 applications. I want to set the start time of the first application of the first client and want to write the rest using a loop.
// iat = interArrivalTime
**.cli[0].app[0].startTime = 1 // define this
**.cli[0].app[1].startTime = <**.cli[0].app[0].startTime> + exponential(<iat>)
**.cli[0].app[2].startTime = <**.cli[0].app[1].startTime> + exponential(<iat>)
.
.
.
**.cli[n].app[m].startTime = <**.cli[n].app[m-1].startTime> + exponential(<iat>)
I looked at the 'ned' functions but could not find any solution.
Of course I can write a script for hardcoding the start times of several clients, but the script would output a huge file which is very hard to manage if the number of clients and applications are too big.
Thank You!
INI files are basically pattern matchers. Each time a module is initialized, the left side of the = sign on each line in the INI file is matched against the actual module path, beginning from the start of the INI file. On the first match from the beginning, the right side of the line is used as the value of the parameter.
In short, these are not assignment operations, rather rules telling each module how to initialize their own parameters. For example it is undefined, in what order these lines will be used during the initialization. Something that is earlier in the INI file is nit necessarily used earlier during module initialization. Of course this prevents you referring an other module's parameter. In fact you may not use any other parameters at all.
In short, INI files are declarative, not procedural constructs so cross references, loops and other procedural constructs cannot be used here.
If you want to create dependencies between module parameters, you can code that in the initialize() method of your module, by explicitly initializing a parameter from the C++ code. You can access any other module's parameter using C++ APIs.
Of course, if you don't want to modify existing applications this is not an optimal solution however you can create a separate module that is responsible for your 'procedural' initialization and that separate module can run through all of you applications and set the required parameters as needed. This approach is used at several places in INET where the initialization data must be computed. One notable example is the calculation of routing table information. e.g. Ipv4FlatNetworkConfigurator
An other approach would be to set up and configure your simulation from a scripting language like python. This is not (yet) supported by OMNeT++ however.
Long story short, write a configurator module and do your initialization there.
A general question about require in Ruby.
My understanding of Ruby's require is that the file specified is only loaded once but can be executed multiple times. Is this correct?
I have a set of Rspec tests in different files which all require the same file logger.rb. It doesn't seem like the methods I call in the required file are executed in every spec.
Here is some of the code I wrote in logger.rb, it first cleans up the temp dir an then creates a logger.
tmpdir = Dir.tmpdir
diagnostics_directory = File.join(tmpdir, LibertyBuildpack::Diagnostics::DIAGNOSTICS_DIRECTORY)
FileUtils.rm_rf diagnostics_directory
raise 'Failed to create logger' if LibertyBuildpack::Diagnostics::LoggerFactory.create_logger(tmpdir).nil?
I'd like this to happen in every spec.
Is that because the tests are within the same module or did I misunderstand how require works.
There is still a great many ifs, as you do not show the code requiring your file, but I think I have understood some of the misunderstandings you had :-)
Your statement 'The file specified is only loaded once but can be executed multiple times.' is basically the opposite of what is true. If a file is to have any effect on a ruby program it will have to be 'executed', it may just happen sometimes that one of the executed methods defines other methods or classes. All statements in a file will be executed once when loaded, but you may load a file multiple times. If you require a file it will only be loaded if it has not been done so already, so as with method definitions your 'static' method calls will only be executed once.
If you want to execute things multiple times you should either load the file (which is usually inefficient since all the compiling will have to be done again) or you require a file with a method definition in it (def ... end) and you call the method multiple times (with possibly varying parameters). The latter is the usual way, as compiling will only have to take place once this way.
I do some examples and i need help with one or few errors. I create : sourse file: Type Include , Status test , Aplication system(Local object).
code:
*&---------------------------------------------------------------------*
*& Include Z_EB_MEMBERLIST13_A_SELECTION *
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK member
WITH FRAME TITLE text-001.
PARAMETERS: par01 AS CHECKBOX,
par02 AS CHECKBOX,
par03 AS CHECKBOX,
par04 AS CHECKBOX.
SELECTION-SCREEN END OF BLOCK member.
activation (ctrl+F3) passes but if i want check syntax (ctrl+F2) show error:
REPORT/PROGRAM statement missing, or program type is I(INCLUDE)
Pls: Where is problem?
thx
The message is only a warning. If this was an executable program the lack of a "REPORT" statement would be a problem; however for include programs, as soon as I include it in any report, It will compile successfully using CTRL+F2
Include programs can not be executed (activated) as it requires that the include is referanced in a program "REPORT" somewhere. From the code you have pasted I think you want to change the program type to "executable program" in attributes of the source program and then include a "REPORT" statement at the top of your file followed by the source filename.
ie.
REPORT Z_EB_MEMBERLIST13_A_SELECTION.
Might be worth having a look at the following link for a full overview.
http://help.sap.com/saphelp_nw2004s/helpdata/en/fc/eb2d5a358411d1829f0000e829fbfe/content.htm
Of note this section taken from above link.
Best of luck.
Include Programs
In contrast to all other program types, include programs do not represent stand-alone compilation units with a memory area of their own. Include programs cannot be executed. They merely serve as a library for ABAP source code. They are exclusively used to organize program texts into small editable units which can be inserted at any place in other ABAP programs using the INCLUDE statement. There is no technical relationship between include programs and processing blocks. Includes are more suitable for logical programming units, such as data declarations, or sets of similar processing blocks. The ABAP Workbench has a mechanism for automatically dividing up module pools, function groups and class pools into include programs. You create your own include programs using the ABAP Editor.
If I write a function or module that calls another module, how can I get the name of the calling function/module? This would be helpful for debugging purposes.
The Stack function will do almost exactly what you want, giving a list of the "tags" (for your purposes, read "functions") that are in the call stack. It's not bullet-proof, because of the existence of other functions like StackBegin and StackInhibit, but those are very exotic to begin with.
In most instances, Stack will return the symbols that name the functions being evaluated. To figure out what context those symbols are from, you can use the Context function, which is aboput as close as you can come to figuring out what package they're a part of. This requires some care, though, as symbols can be added to packages dynamically (via Get, Import, ToExpression or Symbol) and they can be redefined or modified (with new evaluation rules, for instance) in other packages as well.