I can set report format like "./cppcheck --template {file}:{line},{severity},{id},{message}" to get more information, but can not get function name.
Is there any method?
Related
This is a follow up on my previous question - [RobotFramework - Run Tests on different environments
I Have created a file for each of the environments, this is all working, right now I am just using My local tablet to test, I need to point to 10 different devices with different settings, Is there a way to store the configuration dynamically in the arguments file? Like get the configuration using robot store it in a variable and use that value in the arguments file?
Something like
//HERE sample code the get the androidVersion = ${Get_Android_Version}
.args file
--variable REMOTE_URL_ANDROID:http://127.0.0.1:4723/wd/hub
--variable PLATFORM_NAME_ANDROID:Android
--variable PLATFORM_VERSION_ANDROID:${Get_Android_Version}
--variable DEVICE_NAME_ANDROID:Samsung
--variable AUTOMATION_Name_ANDROID:appium
--variable PACKAGE_NAME_ANDROID:DiffrentPackage
--variable ACTIVITY_NAME_ANDROID:PackageName
Ps. I know its not real robot code its just a sample of what i mean.
You cannot have any programming logic in an argument file. Instead of (or in addition to) using an argument file for this, you might want to consider a variable file. Variable files are python code, so you can do any kind of logic you need in order to set your variables.
For example, you could pass the name of the environment from the command line, and use that in your test to import the variables for that environment.
Example
test.robot:
*** Settings ***
Variables ${ENVIRONMENT}_vars.py
...
smoke_vars.py:
def get_platform_version(platform):
<your logic here>
return $version
PLATFORM_NAME = "Android"
PLATFORM_VERSION = get_platform_version(PLATFORM_NAME)
command line:
robot --variable environment:smoke test.robot
You can also specify the variable file on the command line instead of in the test file. For example, you could remove the Variables setting and then do this on the command line:
robot --variablefile smoke_vars.py ...
All of this is very thoroughly documented in the robot framework user guide
I am trying to use the function rebus.pls in the plspm library. This function generates a dendrogram and then prompts for user input (number of desired classes) before proceeding. (Sorry, I cannot provide a code sample as using this function requires a large amount of data.)
I want to produce a static report of my analysis process using knitr. I would be satisfied with either supplying the input during knitting (tedious but produces the desired output), or specifying the input within the Rmd document (preferred solution).
The function rebus.pls is not documented as accepting an optional argument to supply the number of classes. Nor does the documentation give me the name of a global variable I can set in advance. Therefore I believe I'm limited to either supplying the input during knitting, or simulating that by telling knitr in advance "when prompted for user input, use this response." I was unable to find instructions for doing either of those two things; I only found descriptions of how to create interactive HTML output with Shiny.
I am currently generating the reports by using 'knit' in RStudio but could use a *nix command-line solution, e.g.
echo "3" | Rscript -e "library(knitr); knit('Report.Rmd')"
Is this the best I can do or are there other solutions for my problem of "How can I use knitr when using a function which requires user input, when the desired output is a static PDF report using hardcoded input?" I'd prefer something a little more self-documentating.
Bookdown has many configuration options and I am finding it hard to understand how to know whether an option exists, and the logic behind where these options are stated.
Specifically I am finding it hard to describe what kind of options go in _bookdown.yml given that there are at least two other places for stating options:
In _output.yml,
Arguments to function calls such as bookdown::render_book.
It doesn't appear to me that there's any sort of 1 to 1 mapping between _bookdown.yml and arguments to functions like bookdown::render_book, so _bookdown.ymldoesn't seem to be just a different way of recording options to function calls.
We can see in the source code that `_bookdown.yml' is controlling some of the config options but not all of them.
So - to rephrase the question - why is _bookdown.yml a separate config file and where/what is the definition of what it should contain?
To take a representative example, there is a chapter_name option that can be used in _bookdown.yml. I have the following questions:
How are we supposed to know that this is an option, given that it is not referenced in the documentation here or even in the example here.
Once we know it exists, how do I found out what effect it has? Do all of these options get passed to other packages (e.g. pandoc, rmarkdown)? The only place I can find reference to chapter_name is in the CRAN source code for bookdown, and even there I can't really figure out how it's being used.
Note, the discussion of _bookdown.yml by the author is here, but I still don't fully understand.
Here are some results of investigations into the codebase:
We can see that the 'config' variable in bookdown::render_book is populated from _bookdown.yml here, via a function called load_config which can be found in utils.R.
load_config seems to do two things - it stores the contents of config within a master options list called opts, of which config is just one element, and then returns that config element.
Note that opts is initially defined here. It is created from a knitr:::new_defaults which can be found here.
The config variable then appears in multiple parts of the codebase.
The following code is representative:
if (is.na(new_session)) {
new_session = FALSE
if (is.logical(config[['new_session']])) new_session = config[['new_session']]
}
So we can see that if new_session is passed directly to bookdown::render_book as a function argument, it is used. Otherwise an attempt is made to load it from the _bookdown.yml file.
The config is passed around a lot as an argument within bookdown::render_book. So for instance, we can see it being used in the source_files function in utils.R.
What do we conclude? _bookdown.yml allows you to populate a list of global options of the bookdown package. Whenever you see config (which is a list) being using the the codebase, you can set elements of this list by populating _bookdown.yml
I have not managed to find a comprehensive list of the options that can be specified in _bookdown.yml but one way of easily finding out what is possible is to search for examples on Github.
I'm trying to have my LaTeX articles print with both the current date and the time. I found a package called datetime which lets me redefine \today to a variety of formats. But it doesn't have an obvious way to modify \today to include the time, and the code is so twisted that I can't figure it out myself. Is there an easy way to do this?
EDIT
I want to have the time automatically printed with the date on the front page when I run the \maketitle command. As by default, it executes in the hidden command \date{\today}.
Nevermind my comment,
I found something that works without all the makeatletters
\usepackage{datetime}
%...
\title{This is the Title}
\author{An Author's name}
\date{\currenttime}
\maketitle
datetime package provides a \currenttime command. I would recommend using \currenttime directly instead of trying to modify/redefine \today.
I have a custom robot framework library which accepts an argument to initialize it.
*** Settings ***
Library NotifyUsers ${max_messages}
This works just fine when executed from the command line using pybot:
pybot --variable max_messages:4 my_test
However, this variable doesn't exist in Ride when it imports the library at startup. I've tried defining it in the Arguments field on the Run tab, but that isn't instantiated until you run a test.
If I replace the variable and hard code an integer argument, it works fine in Ride.
Apologies to Bryan Oakley! I somehow managed to delete his answer which pointed me in the right direction.
Adding an entry to the variable table does not resolve this issue, however using a Variable File does! It appears that Ride will import variable files when it starts up. Variable Tables contained in a test suite are not resolved until run time.