I'm trying to profile my code using Instruments. What I get is something like the following window:
What I don't understand is: below lq_cohomology, Instruments lists HeapMatrix::pivot. This method is never called directly from lq_cohomology, but only from other functions called by lq_cohomology. Furthermore, I don't understand why `HeapMatrix::pivot shows up multiple times in the profile. Shouldn't that occur only a single time?
Related
I am trying to make my Xamarin.UITest output clearer and easier to work with. Every so often when Xamarin Forms updates the tree changes in subtle ways that break our UITests. Also, when developing a test it isn't always necessarily clear what the query should look like to get to a view element we want our test to interact with.
To address these, when a test fails with an "Unable to find element" error, I want to capture the app's view tree and output it to the test results.
Currently in these cases we have to modify the test code by adding app.Repl(); (see Working With the REPL), re-run the test, wait for the REPL window to appear, type tree, look at the output, type exit to leave the REPL, make my code changes based on what I saw in the tree command's output, and rinse-repeat until I have a working test. Instead, if the test results contains the outputs of the REPL's tree command, I can start making changes to fix the test code immediately and greatly speed up my testing feedback loop.
How could I most easily achieve this?
app.Print.Tree();
I think this is what you searched for.
I am using the Instruments to profile a very simple program. Here is the result:
result
My question is: why the heaviest back trace are annotated on a very simple line of code? I think that line only needs some ALU instructions to implement. Is this a bug or I missed something?
I see nothing unusual in the screenshot you linked to. The 99x line in your screenshot has nothing to do with the heaviness of the backtrace. It is the line of code where Instruments recorded the most samples. The 99x line is inside a loop. Code inside loops is going to execute more often and have more samples.
I have a function that I am trying to examine. I want to find all callers of this function, but there are a few issues:
I am doing this to understand the code because I did not write it, but I need to know exactly how it behaves
It runs through the STL beforehand, so I can't just use something like callgrind to get it's immediate callers
There is a stack trace of 10+ function calls until you get to actual code that is not in the STL that caused this function to be invoked. But those STL entry points vary, as it is a compare function and calls for is_equal go through a different sequence than those that go through not_equal, etc. I will need to do this for at least 10+ different functions, and I want to streamline this as much as possible.
I want a tool that can dump each unique, full backtrace each time the function is called. Does anybody know a tool that can do this?
I am using gdb and c++ on Ubuntu 14.04.
You can make gdb execute a series of commands each time a given breakpoint is executed, e.g.,
break someFunction
commands
bt
continue
end
The feature is mentioned in gdb scripting: execute commands at selected breakpoint, which has a link to the online documentation for gdb 5.1.7 Breakpoint Command Lists
I have an applescript xcode project in xcode 3.2 and am trying to change the system volume...however it doesn't work...it either stops the nstimer or doesnt do anything at all...
Is there a way to log the errors so that I can pinpoint the issue?
Here is my code
set newVolume to 50
set volume output volume newVolume
textName's setStringValue_(currentVolume)
set currentVolume to newVolume
obv this is a much more condense version but this literally does not work...it is inside of an NSTimer but, even when not within an NSTimer it still does not work...newVolume, currentVolume, and textName are all declared...do I need to declare something for the set volume line?
So, your actual question was simply how to log errors from AppleScriptObjC:
AppleScriptObjC will log any errors thrown in your script to the console -- just look in the bottom pane in Xcode. For instance, in your case you should see something like “«script» doesn’t understand the «aevtstvl» message.” (This isn’t terribly clear, but it’s telling you that your script sent a set volume command to a script object, which didn’t have a handler for it.) If you want to capture and log errors yourself, you can put troublesome sections inside a try/on error block, and deal with it yourself in the error handler.
If you’re feeling extra inquisitive, you can also turn on the NSScriptingDebugLogLevel preference, like this:
defaults write com.me.myapp NSScriptingDebugLogLevel 1
...and AppleScriptObjC will log information about every message sent either way across the bridge. (Set it to 0 or use defaults delete to turn it off.)
That’s error logging. Now, what you didn’t actually ask, but I’m going to answer anyway, was “How do I fix my set volume command?”
Short version: add tell current application to:
tell current application to set volume output volume 50
And yes, the range for the “new” volume parameters is 0 to 100. The old compatibility one goes from 0 to 7. (Why? The old Control Panel volume slider had 8 stops.)
Long version:
There’s a bad interaction between the default direct parameter and set volume’s handling of it. When using AppleScriptObjC, “it”, and therefore the default direct parameter, unless you say otherwise, is the current script, and set volume chokes on that. You can force “it” to be nothing by saying tell current application to. (Alternatively, you could give it an explicit direct parameter by using the old-fashioned form set volume x where x is a real number from 0 to 7. However, this doesn’t match the numbers you get from get volume settings, only lets you set the output volume, and doesn’t let you set things like “muted” correctly.)
And by the way, if your AppleScriptObjC project is sufficiently simple (in particular, if you don’t need any interface), you can write it directly in AppleScript Editor: choose File > New from Template > Cocoa-AppleScript Applet, and use the normal AppleScript on run and on open handlers, except that you can now also invoke anything from Cocoa.
i have found myself several times in the need of knowing the last values set to a range of variables that were in a certain portion of code, or method; maybe dispersed around the program.
does anyone know a way to select variables and know the last value set to them after the program ends running - in a windows maybe ?
There isn't anything I know of that will record every value ever assigned to every variable in your program in case you want to look at it later. It is possible with VS2010's historical debugging abilities to look at "values from the past" although I haven't used this yet, so I don't know if that ability extends "beyond death" of the process.
You may also be able to use tracepoints (VS2008 and later). These are like breakpoints, but instead of stopping execution they simply print information to the debug output. So you could add a tracepoint for a variable so that each time it is changed its value is reported (basically the same as printing the values out in your code, but you don't have to change your code to enable them, and can add them while your code is executing).
Two simple approaches that will work for pretty much any dev environment are:
Write the values to an application log each time they change, then read the last reported entries. If you realise you need 5 values from all around the program, simply printing them to the debug output will only take a few seconds to add to your program. (If you can't do this easily, then you're not encapsulating your data very well).
Put a breakpoint on the destructor of the class you're interested in, or at the start of the shutdown process just before you destroy the objects, or the last line of code in your program (for statics) (etc) and just use the debugger to drill down into the data.