Saving values of debug session from watch window to a file - visual-studio

I have to trace some events I want to trace to monitor the operation of a multi-threaded application. For this purpose I defined an array of structs. Each element is one trace record.
enum Event { start, stop, pause };
struct A
{
Event e;
int x, y, z;
};
main()
{
A a[100];
}
There is also a function the writes the event to the array. The array a can be displayed in the watch window of Visual Studio, although not all struct members are displayed:
- a 0x008ff4bc {{e=0xcccccccc x=0xcccccccc y=0xcccccccc ...}, {e=0xcccccccc x=0xcccccccc y=0xcccccccc ...}, ...} A[0x00000064]
+ [0x00000000] {e=0xcccccccc x=0xcccccccc y=0xcccccccc ...} A
+ [0x00000001] {e=0xcccccccc x=0xcccccccc y=0xcccccccc ...} A
+ [0x00000002] {e=0xcccccccc x=0xcccccccc y=0xcccccccc ...} A
Since the array is rather large and the limitation of the watch I want to export the entire array content to a file. This could be done by adding a file export function to the code that is being debugged. But this is no handy, since the debugger is just in a breakpoint and it's not always possible to tell the application to run the export function.
How can I export the array with the values of all members? Is there an option to use the VS command window or probably immediate window to create a text file with the data?

Does it have to be a one-click export? You can select all, copy and paste into your output file. You can do it from Watch window, but the output is a bit more clear from either Immediate or Command windows.
You can beautify the format by creating a custom visualizer in C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Packages\Debugger\Visualizers (use your version of the VS).
Here is how it may look, for example:
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
<Type Name="A">
<DisplayString>({e}:{x},{y},{z})</DisplayString>
</Type>
</AutoVisualizer>

Related

Identify this scripting language/format

This script is part of a legacy code that runs to create a GUI interface for editing text files to be used in analysis codes. There is a windows command script that references a ".sed" file which controls the formatting, editing, and help menu for the GUI. I would like to identify the coding language/rules used in these ".sed" files so that I can make a new more complicated input text file with descriptions of inputs.
Ideally, I would like to be able to use this code to create/edit ".csv" files which can be edited in Excel. This would potentially mean needing to avoid the set variable sizes/padding in the #file block of code below.
Any googling attempts to find more about the coding result in unix sed instructions that are not helpful.
UPDATE: I did find an additional exe in the shell folder of the legacy code for "sedwin.exe". When googled this seems to refer to an old "SEDT text editor for MS-DOS".
An example section from a ".sed" file is below:
<code>
#rem( version description information here )
#version(){"2.0"}
%--------------------------------------------------------------------
#file(seal2,native){
title1(A80);
title2(A80);
title3(A80);
r(G10),del(A1),ll(G10),c(G10),lg(G10),dg(G10),ngroov(I10);
ncase(I10),necc(I10),necase(I10),#for(i,1,necase,0){entlos[i](G10)};
#for(i,1,ncase,0){
speed[i](G10),ro[i](G10),nu[i](G10),delp[i](G10);
}
}
#edit(seal2){
#prompted(22,5,"SEAL2 Input Data"){
#help(){
" Code Name Here
"",
"Code description here"
};
#icon("Titles",titles){#titles();}
#icon("Seal Parameters",seal){#seal();}
#icon("Speed, Fluid Parameters",cases){#cases();}
}
}
#titles(){
#prompted(1,7,"Three Title Lines"){
#help(){
"These title lines will appear on the output of",
"the program.",
"",
"They are useful for identifying the output but",
"do not directly affect the results."
};
#datum("",title1,75,"");
#datum("",title2,75,"");
#datum("",title3,75,"");
}
}
#seal(){
#prompted(12,8,"Seal Parameters"){
#help(){
"Descriptions of inputs in this window.",
};
#datum("Shaft Radius (in)",r,15,"0.");
#float_check("Must be > 0.0","(%g)>0.");
#datum("Land Length (in)",ll,15,"0.");
#float_check("Must be > 0.0","(%g)>0.");
#datum("Seal Radial Clearance (in)",c,15,"0.");
#float_check("Must be > 0.0","(%g)>0.");
#datum("Groove Length (in)",lg,15,"0.");
#float_check("Must be >= 0.0","(%g)>=0.");
#datum("Groove Depth (in)",dg,15,"0.");
#float_check("Must be >= 0.0","(%g)>=0.");
#datum("Number of Grooves (0=plain seal)",ngroov,15,"0");
#int_check("Must be >= 0","(%d)>=0");
#datum("Number of Eccentricities",necc,15,"1");
#int_check("Must be between 1 and 10","(%d)>0&&(%d)<11");
#icon("Entrance Loss Cases",losses){#losses();}
}
}
#new_file(seal2){
file_type=seal2;
unit_type=native;
titles=New;
title1=;
title2=;
title3="(SEAL2 Data File)";
del=",";
seal=New;
ll=0.0;
r=0.0;
c=0.0;
lg=0.0;
dg=0.0;
ngroov=0;
losses=New;
necc=1;
necase=1;
entlos[1...necase]=0.1;
cases=New;
ncase=1;
speed[1...ncase]=0.0;
delp[1...ncase]=0.0;
nu[1...ncase]=0.0;
ro[1...ncase]=0.0;
}
</code>

Finding CPU usage in the XML files exported by Visual Studio 2017's profiler from a VSPX file?

I need to parse the XML files generated by Visual Studio's performance profiler, and get information about CPU usage of each function in my program (similar to what Visual Studio displays in the diagnostics tools and performance profiler).
I tried looking through all the XML files that I can generate using the tool (call tree summary, function summary, process summary, etc.) but I don't seem to find the information regarding CPU usage.
Which XML views should I export to get this information? Also, where can I find CPU usage? What are InclSamples and ExclSamples? Here is an example from my function summary XML:
<Function FunctionName="MatrixMultiply.Program.FunctionName" InclSamples="1,444" ExclSamples="881" InclSamplesPercent="97.30" ExclSamplesPercent="59.37" />
For generating the XML files correctly, you have to choose a target and checkbox the analyze CPU Usage in the Performance Profiler (Alt + F2) which is available in Debug > Performance Profiler from the menu dropdown. This window is the diagsession window which asks you to choose the performance reports you need and start the profiling.
- CPU Usage
- Memory Usage
- GPU Usage
Once you export the report into a VSPX file, VS2017 allows you to export this binary file into readable CSVs/XML files. In the menu that shows up, you could choose different reports you'd like. Some of the reports that the profiler can generate for you are:
Caller Callee Summary
Call Tree Summary
Function Summary
Header Summary
IP Summary
Line Summary
Marks Summary
Module Summary
Process Summary
Process Thread Summary
Thread Summary
It looks like you're most interested in the CallTreeSummary, the exported XML file will have the name <reportname>_CallTreeSummary.xml which contains the <PerformanceReport> consisting of <CallTreeSummary>
Each CallTree call in the CallTreeSummary contains the functionName, the InclSamples, ExclSamples and their respective percentages.
Here's an example:
For a sample C++ code as follows (Memory leak sample):
int main() {
while (true) {
int *p = new int;
}
return 0;
}
A part of the CallTree shows up as follows:
<CallTree Level="8" FunctionName="operator new" InclSamples="20,560" ExclSamples="78" InclSamplesPercent="97.46" ExclSamplesPercent="0.37" ModuleName="Sample.exe" />
<CallTree Level="9" FunctionName="[ucrtbased.dll]" InclSamples="20,482" ExclSamples="55" InclSamplesPercent="97.09" ExclSamplesPercent="0.26" ModuleName="ucrtbased.dll" />
<CallTree Level="10" FunctionName="[ucrtbased.dll]" InclSamples="20,427" ExclSamples="83" InclSamplesPercent="96.83" ExclSamplesPercent="0.39" ModuleName="ucrtbased.dll" />
<CallTree Level="11" FunctionName="[ucrtbased.dll]" InclSamples="20,344" ExclSamples="177" InclSamplesPercent="96.44" ExclSamplesPercent="0.84" ModuleName="ucrtbased.dll" />
<CallTree Level="12" FunctionName="[ucrtbased.dll]" InclSamples="20,119" ExclSamples="2,092" InclSamplesPercent="95.37" ExclSamplesPercent="9.92" ModuleName="ucrtbased.dll" />
InclSamples represents the total number of ticks taken to execute the function and any related functions that are called.
ExclSamples represents the total number of ticks taken to execute only the function.
For an illustrative example, consider the following example:
int bar() {
return 1;
}
int foo() {
return bar();
}
int main() {
int x = foo();
return 0;
}
A sample execution could show the following data:
<FunctionName="main" InclSamples="100" ExclSamples="10" InclSamplesPercent="100.00" .../>
<FunctionName="foo" InclSamples="90" ExclSamples="40" InclSamplesPercent="90.00".../>
<FunctionName="bar" InclSamples="50" ExclSamples="50" InclSamplesPercent="50.00" .../>
This is interpreted as follows:
Running the main() function takes 100 CPU ticks in total but only 10 of those ticks resulted in executing this function, leaving us with 90 ticks which were used in other functions being called from main()
Running the foo() function takes 90 CPU ticks (since it includes the run time of foo() + bar() but exclusively the foo() takes 40 ticks.
The bar() function takes 50 ticks to run.
Using the reasoning above, you could reason the CallTree sample provided above. The associated InclSamplesPercent is the percentage of time taken by the CPU to run the overall task. For e.g. from the sample above we can say that 100% of the CPU usage was by the main() function but 90% of that was taken up by foo() function and 50% by bar() function effectively making the ExclSamplesPercent by foo() as 90 - 50 = 40.00% and ExclSamplesPercent by main() as 100 - 90 = 10%

Plot code does not work in R Studio but does in R

i am trying to move plot results in to rmarkdown in R studio
the following code fails
```{r front_stuff ,echo=FALSE,fig.height=3,fig.width=4}
library(ggplot2)
library(cowplot)
library(lubridate)
library(reshape2)
library(htmlTable)
library(data.table)
library(png)
project_folder<-"C:\\Users\\jciconsult\\SkyDrive\\trial_retail\\"
load(paste0(project_folder,"sa_prov_html.RSave"))
load(paste0(project_folder,"Ontario_plot_save.RSave"))
ls()
```
`r ggdraw(cow_plot1)`
Error message is
Quitting from lines 29-29 (test1.Rmd)
Error in vapply(x, format_sci_one, character(1L), ..., USE.NAMES = FALSE) :
values must be length 1,
but FUN(X[[1]]) result is length 2
Calls: ... paste -> hook -> .inline.hook -> format_sci -> vapply
Execution halted
If I take the same code and copy it into a clear R session (eliminating the stuf for code blocks), everything works.
What I am trying to do is get a document that can convert to word. I am using the knit HTML option because that is needed to get my htmlTable output to work.
I want something that I can cut and paste into word for final formatting,
The plot cannot be drawn because it is inline code. Try using a code chunk instead:
```{r}
ggdraw(cow_plot1)
```
Also, the proper way to set a working directory with knitr (which seems to be what you want to achieve) is with the knitr option root.dir:
library(knitr)
opts_knit$set(root.dir = project_folder)
load("sa_prov_html.RSave")
load("Ontario_plot_save.RSave")

Docpad: confused about extending template data

I'm totally confused about adding mongo data to template data. I haven't even started trying to get the data from a database as I can't get my templates to see test data (see below). This is in docpad.coffee for the moment, but ultimately g will be the output of mongoDB.
events:
extendTemplateData: (opts) ->
# {templateData} = opts
getGigsData: ->
g = { "date" : "3-4-2013", "location" : "Gent" }
return g
opts.templateData["getGigsData"] = getGigsData
And I hope to access it with <%= #getGigsData().date %>
Thanks so much for some guidance
I should add that this design is based on wanting to make it easy for the band to add gigs, without letting them edit the page content itself as I fear they would mess up the markup - if there are other ways to achieve this goal, I'd be pleased to hear.
Tried this locally. And hit the issue:
debug: Emitting the event: extendTemplateData
→ [2014-02-14 01:38:50.030] [/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/docpad.js:1184] [DocPad.emitSerial]
error: Something went wrong with the action
→ [2014-02-14 01:38:50.037] [/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/interfaces/console.js:107] [ConsoleInterface.destroyWithError]
error: An error occured:
ReferenceError: getGigsData is not defined
at Object.docpadConfig.events.extendTemplateData (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/docpad.coffee:42:44)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:25:27)
at DocPad.<anonymous> (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/docpad.js:995:25)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:23:18)
at Task.<anonymous> (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/event-emitter-grouped/out/lib/event-emitter-grouped.js:45:23)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:23:18)
at fire (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/taskgroup/out/lib/taskgroup.js:163:25)
at b (domain.js:183:18)
at Domain.run (domain.js:123:23)
at Task.fire (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/taskgroup/out/lib/taskgroup.js:173:25)
at processImmediate [as _immediateCallback] (timers.js:330:15)
Which indicates that the error is actually inside our event handler, rather than inside our code. That for some reason getGigsData is not being set, despite our:
getGigsData: ->
g = { "date" : "3-4-2013", "location" : "Gent" }
return g
Examining the code, as a CoffeeScript user, I found the issue. As a non-coffeescript user, you can use the coffeescript compiler on the coffeescript website http://coffeescript.org to see the compiled javascript, which is:
({
events: {
extendTemplateData: function(opts) {
({
getGigsData: function() {
var g;
g = {
"date": "3-4-2013",
"location": "Gent"
};
return g;
}
});
return opts.templateData["getGigsData"] = getGigsData;
}
}
});
As we can see that is definitely not what we expected. We are just defining getGigsData inside an object, then doing nothing with it.
The issue is that we used a colon instead of an equals sign, so getGigsData: -> instead of getGigsData = ->. This is not a coffeescript thing, but you would have run into the same issue if this was javascript too, albeit javascript may be a bit more obvious due to the necessary squiggly braces around object definitions.
As a sidenote, if you prefer to use JavaScript with DocPad for whatever reason, that is totally supported. You could use a docpad.json or docpad.js file for your docpad configuration file. Another option, is to continue using CoffeeScript then just wrap JavaScript code within the backtick, see: http://coffeescript.org/#embedded

Forcing a package's function to use user-provided function

I'm running into a problem with the MNP package which I've traced to an unfortunate call to deparse (whose maximum width is limited to 500 characters).
Background (easily skippable if you're bored)
Because mnp uses a somewhat idiosyncratic syntax to allow for varying choice sets (you include cbind(choiceA,choiceB,...) in the formula definition), the left hand side of my formula call is 1700 characters or so when model.matrix.default calls deparse on it. Since deparse supports a maximum width.cutoff of 500 characters, the sapply(attr(t, "variables"), deparse, width.cutoff = 500)[-1L] line in model.matrix.default has as its first element:
[1] "cbind(plan1, plan2, plan3, plan4, plan5, plan6, plan7, plan8, plan9, plan10, plan11, plan12, plan13, plan14, plan15, plan16, plan17, plan18, plan19, plan20, plan21, plan22, plan23, plan24, plan25, plan26, plan27, plan28, plan29, plan30, plan31, plan32, plan33, plan34, plan35, plan36, plan37, plan38, plan39, plan40, plan41, plan42, plan43, plan44, plan45, plan46, plan47, plan48, plan49, plan50, plan51, plan52, plan53, plan54, plan55, plan56, plan57, plan58, plan59, plan60, plan61, plan62, plan63, "
[2] " plan64, plan65, plan66, plan67, plan68, plan69, plan70, plan71, plan72, plan73, plan74, plan75, plan76, plan77, plan78, plan79, plan80, plan81, plan82, plan83, plan84, plan85, plan86, plan87, plan88, plan89, plan90, plan91, plan92, plan93, plan94, plan95, plan96, plan97, plan98, plan99, plan100, plan101, plan102, plan103, plan104, plan105, plan106, plan107, plan108, plan109, plan110, plan111, plan112, plan113, plan114, plan115, plan116, plan117, plan118, plan119, plan120, plan121, plan122, plan123, "
[3] " plan124, plan125, plan126, plan127, plan128, plan129, plan130, plan131, plan132, plan133, plan134, plan135, plan136, plan137, plan138, plan139, plan140, plan141, plan142, plan143, plan144, plan145, plan146, plan147, plan148, plan149, plan150, plan151, plan152, plan153, plan154, plan155, plan156, plan157, plan158, plan159, plan160, plan161, plan162, plan163, plan164, plan165, plan166, plan167, plan168, plan169, plan170, plan171, plan172, plan173, plan174, plan175, plan176, plan177, plan178, plan179, "
[4] " plan180, plan181, plan182, plan183, plan184, plan185, plan186, plan187, plan188, plan189, plan190, plan191, plan192, plan193, plan194, plan195, plan196, plan197, plan198, plan199, plan200, plan201, plan202, plan203, plan204, plan205, plan206, plan207, plan208, plan209, plan210, plan211, plan212, plan213, plan214, plan215, plan216, plan217, plan218, plan219, plan220, plan221, plan222, plan223, plan224, plan225, plan226, plan227, plan228, plan229, plan230, plan231, plan232, plan233, plan234, plan235, "
[5] " plan236, plan237, plan238, plan239, plan240, plan241, plan242, plan243, plan244, plan245, plan246, plan247, plan248, plan249, plan250, plan251, plan252, plan253, plan254, plan255, plan256, plan257, plan258, plan259, plan260, plan261, plan262, plan263, plan264, plan265, plan266, plan267, plan268, plan269, plan270, plan271, plan272, plan273, plan274, plan275, plan276, plan277, plan278, plan279, plan280, plan281, plan282, plan283, plan284, plan285, plan286, plan287, plan288, plan289, plan290, plan291, "
[6] " plan292, plan293, plan294, plan295, plan296, plan297, plan298, plan299, plan300, plan301, plan302, plan303, plan304, plan305, plan306, plan307, plan308, plan309, plan310, plan311, plan312, plan313)"
When model.matrix.default tests this against the variables in the data.frame, it returns an error.
The problem
To get around this, I've written a new deparse function:
deparse <- function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
}
However, when I run mnp again and step through, it returns the same error for the same reason (base::deparse is being run, not my deparse).
This is somewhat surprising to me, as what I expect is more typified by this example, where the user-defined function temporarily over-writes the base function:
> print <- function() {
+ cat("user-defined print ran\n")
+ }
> print()
user-defined print ran
I realize the right way to solve this problem is to rewrite model.matrix.default, but as a tool for debugging I'm curious how to force it to use my deparse and why the anticipated (by me) behavior is not happening here.
The functions fixInNamespace and assignInNamespace are provided to allow editing of existing functions. You could try ... but I will not since mucking with deparse looks too dangerous:
assignInNamespace("deparse",
function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
} , "base")
There is an indication on the help page that the use of such functions has restrictions and I would not be surprised that such core function might have additional layers of protection. Since it works via side-effect, you should not need to assign the result.
This is how packages with namespaces search for functions, as described in Section 1.6, Package Namespaces of Writing R Extensions
Namespaces are sealed once they are loaded. Sealing means that imports
and exports cannot be changed and that internal variable bindings
cannot be changed. Sealing allows a simpler implementation strategy
for the namespace mechanism. Sealing also allows code analysis and
compilation tools to accurately identify the definition corresponding
to a global variable reference in a function body.
The namespace controls the search strategy for variables used by
functions in the package. If not found locally, R searches the package
namespace first, then the imports, then the base namespace and then
the normal search path.

Resources