There is a 'Code Coverage Results' window in Visual Studio which allows you to view the contents of a *.coverage file (generated by one of the VS performance tools). I was wondering if there was a way to export the Code Coverage Results to excel for further analysis. The tools in the Code Coverage Results window seem somewhat limited and was wondering if I was missing something.
I've queried quite a few statements and cannot find the answer I was hoping to find. There were three main questions which did not seem to have answers:
Can you search the data within the code coverage results? The typical VS search will not allow you to search within the Code Coverage Results window
Can the Code Coverage Results be exported to excel, or as a *.csv file? If not, then can the *.coveragexml file (which seems to be the only export option) be imported into excel in a way that i would get a table similar to the one in the Code Coverage Results window?
Is there an 'Expand All'/'Collapse All' button for the Code Coverage Results window? It would be nice to be able to expand all of the Code Coverage Result tree if possible ... or at least be able to expand a group of branches which have been expanded.
Any suggestions/input would be useful.
What you can do is this:
Export to XML (I renamed it to ...coverage.xml so it is recognized as an XML file but not sure if that's necessary)
Load with Visual Studio
Format in VS (Ctrl+K, Ctrl+D)
Now you can open this in Notepad++ for example (or any other good XML viewer). There you choose to close or open all text blocks.
Related
I am using the rmarkdown with the rshiny for generating word file reports. I am using the R studio-server for development. On executing the rshiny application, it halts due to some error in the one of the rmarkdown.
The error says...
Quitting from lines 11-486 (/home/KS127/dev/shiny_apps/pashiny/inst/shiny/dataframe_source.Rmd)
Quitting from lines NA-486 (/home/KS127/dev/shiny_apps/pashiny/inst/shiny/dataframe_source.Rmd)
It's providing the line numbers which are not useful to identify the root cause. Adding print statements are also not useful as I am generating the word file report, until and unless the complete .Rmd doesn't get successfully executed, I won't be able to see print statements output.
I tried changing the rmarkdown output setting from chunk output inline to chunk output to console as mentioned here as well but it is of no use.
Is there any way to print the .Rmd file print statements or the output to the console or is there any way to debug the .Rmd file?
In addition to my comment above, Abhinandan, I've recently stumbled across a new package, called testrmd.
Although it is new, it seems to work with a number of different test packages and provides a useful front-end for Rmarkdown documents. (I'm certainly going to use it.)
You might want to check it out. Here's the link: https://github.com/ropenscilabs/testrmd.
I hope this helps you.
See My .Rmd file becomes very lengthy. Is that possible split it and source() it's smaller portions from main .Rmd?
That's what I do. -
Split your code chunks in separate files and add them one by one
SAS Forecast Studio is a programming tool that is used for business intelligence forecasting. It (presumably) generates SAS code on the back end that then produces the output.
Is there any way to get access to the generated SAS code that was used to produce the output, and save it as a .SAS file, a program in the project, or to the clipboard?
Late answer, but I hope it can be useful for someone;
The SAS code is available from the Forecast Studio.
Access your project, click "Project" in the menu bar and select "SAS Code..."
I'm using the listings package in LaTeX to include source code, but some of my source code runs off to the right and so some lines are obviously too long. Does anyone know if there is a way to mark the margin when I'm writing the code, perhaps depending on the \setlength parameters I set in my LaTeX environment so that I know to stop there? I'm using Microsoft Visual C++ 2010 and TeXworks for this particular problem, but I often just use Emacs to write both C++ code and LaTeX.
Here's a snippet from LaTeX I'm using:
\lstdefinestyle{C++}
{float=h!, frame=single, language={[Visual]C++}, numbers=left, numberstyle=\tiny, tabsize=2}
\lstinputlisting[style=C++, label=lst:RANDU, caption=RANDU C++ Implementation]{RANDU.cpp}
Here's a snippet of what the output of this looks like, I'd like to know where to end lines in my IDE so that it doesn't exceed the right border:
Thanks in advance!
You could use packages like fill-column-indicator or column-enforce-mode. Both available also with MELPA.
The downside is that you will need to manually update the number of columns you want when you update your \setlength, unless you write some code to do it for you.
Use: breaklines=true in the options. Example:
\lstdefinestyle{C++}
{
float=h!, frame=single, language={[Visual]C++}, numbers=left, numberstyle=\tiny, tabsize=2, breaklines=true
}
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm a great fan of R markdown, finding it even easier than weaving LaTeX for quick project documentation (less than 15 pages). However, I also have to support sometimes other Statistics packages (SPSS, Stata + SAS) and was wondering for equivalent solutions for these.
To some extend this might go back to using some kind of original Noweb code + markdown file to be compiled over the command line. I guess calling the other packages from R is another option.
I have had a look at this example by John Muschelli: http://rpubs.com/muschellij2/3888 and it looks as though he knitted Stata code into an R markdown file.
Can someone provide specific examples of how this can be done in Stata, SAS or SPSS?
I do know of SASweave and StatWeave (the latter is apparently broken???), but think that a markdown solution would be far more advantageous in our case.
Stata has its own SMCL for annotation of logs, the M standing for mark-up. The main reason for a different language is that SMCL has to be created and interpreted line by line in situations where no end of document is in sight, namely within interactive sessions. This is created by Stata automatically as annotation when you ask for it and can be stipulated by users or programmers as a way of tuning Stata's display choices.
The possible connection to your question is that SMCL can be translated to HTML, which opens various doors. So, something that is easy in Stata is to do some work, keep a log file in SMCL and then translate the log file to HTML. You would not get anything really nice without further work, but the further work is easy and amounts to doing what you would done any way, but in your favourite text editor or text processor, rather than within Stata.
This is made easier by log2html which Stata users can install using ssc inst log2html. It exploits a feature undocumented in Stata.
Stata's help files can also be translated to HTML in the same way (but consider copyright issues if doing this with official help files; it's fair play with your own help files).
John Muschelli pointed me to this Stata program:
https://github.com/amarder/stata-tutorial/blob/master/knitr.do
It parses a .domd file which contains markdown and Stata code and produces a .md file with executed Stata code. The name of the file to be parsed is at the end of the knitr.do file.
More specifcally:
Download the knitr.do file from https://github.com/amarder/stata-tutorial/blob/master/knitr.do
Download the clustered-standard-errors.domd file from https://github.com/amarder/stata-tutorial/blob/master/clustered-standard-errors.domd
Save them both in some directory.
Modify the last line of knitr.do to reflect the complete path of its directory (e.g.
D:\Desktop\knit_example\clustered-standard-errors.domd
Run knitr.do to get your markdown (.md) file (and an intermediate .md1 file).
Note that knitr.do contains the programs that do the work and a line (the last one):
knit "whatever-file.domd"
that calls the program.
So you basically write a .domd file [that of step (2) is only an example] containing Markdown syntax and Stata commands, run knitr.do adjusting the file name, and get a Markdown file with executed Stata commands.
There are several caveats:
Only one-liner Stata commands are allowed. A loop, for example, won't work.
".domd" can't be part of the file name.
If there is an error with a Stata command, the user gets no return code.
File handles need to be manually closed if user hits the Break button when the program is running or if there is a Stata command error.
I'm not sure if this is what you want, but if you're looking to create .html files in SAS that contain statistical reports within them, then you can use the Output Delivery System (ODS).
Example syntax is:
ods html file='pathofdirectory\filename.html' <additional options>;
proc print... (SAS code that generates output)
proc means...
proc freq...
proc gchart...
proc gplot...
...
ods html close;
SPSS (and SAS I presume) have some overhead by the need to write everything to disk that makes the compilation in one fell swoop less appealing. Similar as to what Yick mentioned, SPSS has an output system that one can write automated reports to begin with and export to HTML or PDF or Word. It isn't the easiest thing to make look nice, but it is possible and additions to ease automated editing (mainly via Python scripts) are being rolled out on a regular basis.
Basically the automated reports I write now using SPSS and R have html shells. The code then just updates or inserts the needed tables and graphs. They are entirely self-contained, reproducible, and run on weekly or monthly timers without human intervention. They just don't have inline code blocks exactly defining how the tables are produced (you would have to trace the code slightly further back to figure it out - but that isn't too onerous IMO).
Because SPSS allows you to run SPSS code from the Python command prompt you could theoretically knit a document with Python code calling SPSS. I'm not quite sure I see the advantage of this over having more segmented code in seperate places though. Do you really want to read 100 lines of SPSS code that begins with an SQL query, does some transformations and produces a table and a graph? Wouldn't you rather see the table and graph, and then if interested in the nitty gritty go back to see DataPrep.sps that prepares all of the data, then see Table1.sps and Figure1.sps etc. to see how they each were exactly produced?
In many banks, people use all kind of addins mostly programmed in C++ to compute various risks and values.
My question is: considering an Excel environment with in-house Excel addins doing most of the work. Is there a format of debug information you would recommend to generate useful debug information which could be readable and avoid our developers to systematically have to debug the code using Visual Studio ?
At the moment, what I do is that in my code, I generate .csv files containing the intermediate computations in a readable format.
The files have tickers such as Risk-1-Stock-2012-08-13_8h33m00.csv which are generated on the fly and optionally produced in the temp folder. The problem is that, while it fits my purpose, it does not seem flexible enough to be used by everyone else and some other people have had their own implementations within the same project of a similar set of functions.
Maybe someone here has a 'silver bullet' which would make reporting debug information in a standard and readable format much easier ?