Let's say one file is compiled and is in running mode and it is using some macro.Is there any way to check what value of the macro that is being used by the file.
eg if the file contains
-define(TIMEOUT,200).
From terminal how can i check what TIMEOUT definition is being used by the file.
Why I want is because suppose file is in running mode and i changed the macro definition in between and forgot to compile the file. I want to confirm what defintion it is taking.
Macros do not survive even the earliest stages of the compilation as the preprocessor substitutes them immediately in the source. You will have to define and export a separate function to see their values, something like:
macro_values() ->
[{'TIMEOUT',?TIMEOUT},...].
You can then call this from the shell and get the values that were substituted.
Related
Is it possible to customize the Build Configuration dump which is printed at the very beginning of each bitbake call? I'm using different flags and overrides to fine tune things like development/testing/deployment mode and I would to have these printed to the terminal to make sure I didn't miss stetting any important flags.
Is that possible? If yes, how can this be achieved?
The output of the Build Configuration is configured by the variable BUILDCFG_VARS defined in the bitbake.conf file.
You can i.e. append values to it in your local.conf. I think the output is evaluated early, so it might not use the values that would be used in a particular recipe.
I am trying to run tests in UFT by running a .vbs file. I am also passing arguments through command line. .vbs file reads the arguments and sets the environment variable of UFT. Hence, I can read them inside UFT.
qtApp.Test.Environment.Value("First_Argument") = WScript.Arguments.Item(0)
qtApp.Test.Environment.Value("Second_Argument") = WScript.Arguments.Item(1)
After that, I want to get a number as an output from UFT because I will use that output to pass it to the next command in command line.
The Test Parameters Object can be a way , more detailed in the Automation Object Documentation
You will have to define the TestParameters of the TestCase from the UFT IDE(manually) there is no way to define them automatically. If you declare them as in and out type, and change their value as a part of a Test Case, you would be able to read it afterwards from the vbs (Do not open a new Test Case until you did not read out the preferred values)
Although this is a working (and standard) way for exchanging parameters between the driver script and the TA Robot(UFT) I would advise you to use a simple file based way of doing this - managing test parameters can be very time consuming.
Tell the script via an Environment variable the path of the xml / json or simple text file where you expect the results to be written and when the test is done, read the content of the file (assuming the test will write into that file)
The plain old file way should not be underestimated especially in such circumstances.
So I have a script that takes an input and prints whatever. It needs access to a file written by a third party. My Xcode project structure is just two files, main.swift and ThirdParty.swift. If I just run it from Xcode main.swift happily sees ThirdParty.swift and I'm apply to instantiate an object defined within. When I run from the command line it cannot find ThirdParty.swift (which is pretty much to be expected; how would it know it's there?).
None of the command line options to pass to /usr/bin/swift seem to be appropriate for pointing to a file I'd like to use and pointing it to the current directory doesn't work either. Is this even possible or should I just give up?
The ideal end result is the ability to do something like:
./main.swift --option1 --option2 thing
But an acceptable place to end up would be:
swift -X ThirdParty.swift main.swift --option1 --option2 thing
Where X is whatever option I need to be passing in.
You can't pass two files into "immediate" mode (swift REPL mode) but you have several other options:
Combine the files together on the fly into a temporary file (with e.g. /bin/cat)
Compile the two files into a normal binary with swiftc.
I recommend option 2, though it means every time you change the code you'll need to recompile, and the binaries it creates aren't portable between OS X and Linux.
I need to read a file with input parameters for my test. However I dont want to hardcode the name of the file into the code.
How can I specify the name of the file from the command line for compiled e code?
Is there another way to do it for loaded e code? Why wont this work for compiled code?
The generic solution would be to use the new sn_plus mechanism.
From command line add something like +my_file=filename
From your code you can access the argument with special functions sn_plusargs_exist to check if there is such argument, and read its value with sn_plus_value.
Another solution is passing filename as define from the command line, with -c flag, and inside your code read the file named with that define.
However, it doesn't work with compiled e code, since the defines are already calculated at compiling time.
You can use the sn_plusargs_value() and sn_plusargs_exist() in your code.
Now you can pass your arguments file via command line with no need to re-compile your e code.
Alternatively you can set an environment variable and retrieve its value in the e-code using
var filename := get_symbol("<VAR>")
Currently, running prove with TAP::Formatter::JUnit supports an environment variable PERL_TEST_HARNESS_DUMP_TAP that sets a path where a directory t/ will be created, and for each test file x, new files named x and x.junit.xml are created in the directory. I would like to be able to format the output filenames in a different way. Is there any way to do this?
A quick look at TAP::Formatter::JUnit::Session says "no" - there is no way to modify it without writing your own formatter, deriving off TAP::Formatter::JUnit and overriding its open_test method to point to your own session, which would, in turn, be derived off TAP::Formatter::JUnit::Session with its dump_junit_xml overridden to do what you want - but now you're modifying the entire dump (and thus don't need to rely on that environment variable if you prefer).
I guess all that derivation is a way, though probably not the way you thought/were hoping.