I have both CALL_GRAPH and CALLER_GRAPH set to YES, and doxygen happily generates both call and caller graph for me, however is there a command or trick to merge these two graphs to a single "flow" graph?
That is, instead of a->B and B->c how do I get a->B->c?
Related
The vscode-antlr4 plugin for VisualStudio Code has a nice call-graph feature which visualizes (as a dendrogram) how grammar (and lexer) rules interact. You can save the graphic as SVG.
Is there a way to export the information as JSON? I wouldn't mind going into the plugin's code to find a way to do it.
My aim is to create reachability graphs for individual rules, i.e. graphs that show from which other rules a particular rule can be reached (transitively). The "calls" and "is-called" information from the call-graph feature would be a nice starting point.
The data for the call graph comes from a source context instance (for each grammar file there's a single source context to manage all details for it). See the function getReferenceGraph, which collects the relations into a map object. You can use that object to generate a JSON object from it. Or you create another function, taking this one as template, to generate the JSON directly, without the overhead required for the UI.
I'm trying to find if functionX is ever called by functionY by way of any other number of functions (let's call them functionA, functionB, and functionC) in a large codebase that fortunately does not make excessive use of callback functions.
I'm clicking through doxygen include-dependency-graphs manually (read inefficiently). How can I search more effectively? Can ag save me?
Example call graph:
taken from: https://codeyarns.com/2013/12/24/how-to-create-header-include-graph-using-doxygen/
Change DOT_CLEANUP = NO in your configuration and run Doxygen again
Find the call graph dot file for functionX (will have a similar name as to the image generated, but with a .dot extension)
Search that dot file for functionY.
You can equally search for functionX in the caller graph .dot file of functionY.
BTW, you didn't post a call graph image; you posted an include tree. I assume that was that a mistake, and that you do have CALL_GRAPH=yes (and/or CALLER_GRAPH=yes).
In Paper [A Software Product Line for Static Analyses(2014)], there is an illustration related constructing call graph(Listing7).
In this example, Line14 is related to construct call graph. while i check the src code and API, what i could find is DefaultCHACallGraphDomain.scala which has no implementation of construct call graph.
As my purpose is using OPAL to construct call graph. Is there any demo or documents help me understanding existing CallGraphDomain in OPAL? currently, i can only find some class declaration.
I'll be really appreciated if anyone can give me some suggestions related this topic.
Thanks in advance.
Jiang
The interface that was shown in the paper doesn't exist anymore, so you can totally forget about it.
The default interface to get a CallGraph class is provided by the Project object you retrieve when you load the bytecode a Java project.
A general code Example:
val project = ... // a java project
val computedCallGraph = project.get(/* Some call graph key */)
val callGraph = computedCallGraph.callGraph // the final call graph interface.
The computed call graph contains several things. It contains the entry points, unresolved method calls, exceptions when something went wrong at the construction time and the actual call graph.
OPAL provides you several call graph algorithms, you can retrieve each by passing the corresponding call graph key to the Project's get method.
Currently, the following two keys are available and can be passed to Project.get (more information is available in the documentation of this classes):
CHACallGraphKey
VTACallGraphKey
Analysis mode - Library vs Application
To construct a valid call graph for a software project it depends on the project kind which analysis mode to chose. While applications provide complete information (except incomplete projects, class loading and so on), software libraries are intended to be used by other projects. However, those two different scenarios have to be kept in mind, when construction call graphs. More details can be found here: org.opalj.AnalysisModes
OPAL offers the following analysis modes:
DesktopApplication (safe for application call graphs)
LibraryWithClosePackagesAssumption (safe for call graphs that are used for security-insensitive analyses)
LibraryWithOpenPackagesAssumption (very conservative/safe for security analyses)
The analysis mode can be either configured in OPAL's config file or set as project setting at runtime. You can find the config file in the Common project under /src/main/resources/reference.conf.
All of those analysis modes are supported by the the CHACallGraphKey while VTACallGraphKey only supports applications so far.
NOTE: The interface may change in upcoming versions again.
Let us say that I have a Matlab function and I change its signature (i.e. add parameter). As Matlab does not 'compile' is there an easy way to determine which other functions do not use the right signature (i.e. submits the additional parameter). I do not want to determine this at runtime (i.e. get an error message) or have to do text searches. Hope this makes sense. Any feedback would be very much appreciated. Many thanks.
If I understand you correctly, you want to change a function's signature and find all functions/scripts/classes that call it in the "old" way, and change it to the "new" way.
You also indicated you don't want to do it at runtime, or do text searches, but there is no way to detect "incorrect" calls at "parse-time", so I'm afraid these demands leave no option at all to detect old function calls...
What I would do in that case is temporarily add a few lines to the new function:
function myFunc(param1, param2, newParam) % <-- the NEW signature
if nargin == 2
clc, error('old call detected.'); end
and then run the main script/function/whatever in which this function resides. You'll get one error for each time something calls the function incorrectly, along with the error stack in the Matlab command window.
It is then a matter of clicking on the link in the bottom of the error stack, correct the function call, and repeat from the top until no more errors occur.
Don't forget to remove these lines when you're done, or better, replace the word error with warning just to capture anything that was missed.
Better yet: if you're on linux, a text search would be a matter of
$ grep -l 'myFunc(.*,.*); *.m'
which will list all the files having the "incorrect" call. That's not too difficult I'd say...You can probably do a similar thing with the standard windows search, but I can't test that right now.
This is more or less what the dependency report was invented for. Using that tool, you can find what functions/scripts call your altered function. Then it is just a question of manually inspecting every occurrence.
However, I'd advise to make your changes to the function signature such that backwards compatibility is maintained. You can do so by specifying default values for new parameters and/or issuing a warning in those scenarios. That way, your code will run, and you will get run-time hints of deprecated code (which is more or less a necessary evil in interpreted/dynamic languages).
For many dynamic languages (and MATLAB specifically) it is generally impossible to fully inspect the code without the interpreter executing the code. Just imagine the following piece of code:
x = magic(10);
In general, you'd say that the magic function is called. However, magic could map to a totally different function. This could be done in ways that are invisible to a static analysis tool (such as the dependency report): e.g. eval('magic = 1:100;');.
The only way is to go through your whole code base, either inspecting every occurrence manually (which can be found easily with a text search) or by running a test that fully covers your code base.
edit:
There is however a way to access intermediate outputs of the MATLAB parser. This can be accessed using the undocumented and unsupported mtree function (which can be called like this: t = mtree(file, '-file'); for every file in your code base). Using the resulting structure you might be able to find calls with a certain amount of parameters.
I am using the publishing functionality of MATLAB to generate a quick report of some analysis I'm running. Since the analysis is quite time-consuming, I've added a progress bar to keep track of how long is remaining. The problem is that I'd prefer this progress bar not to appear in my report.
Is there a way to keep MATLAB from introducing some content in a published document. Or, alternatively, is there a way I can know I'm currently in publish mode, so I can skip the progress bar in those cases?
Edit:
There's a couple of solutions already, but I'd prefer something automatic that doesn't require an extra step in the workspace before publication. Any other tricks?
AFAIK there is no way of excluding parts from published document.
Perhaps what you can do is to output a unique pattern (BEGIN/END) around the progress bar code, which you will then parse the html file and remove those sections using some script.
I'm assuming you're using the WAITBAR function to generate a progress bar, and you have only one of these waitbars in your function.
Before you publish the file pre-create the waitbar:
h = waitbar(0);
Then make the waitbar invisible to the PUBLISH function:
set(h,'HandleVisibility','off')
Where you use the waitbar in your code, you have to specify that you want to reuse the hidden waitbar by referring to it again, with the handle, h:
waitbar(newPercentage,h);
see the function reference page for waitbar for more help.
Another slightly more generic option (inspired by Mike Katz' response), which works for any kind of content you don't want (or explicitly want) to include in your report.
in your module/function
try
inPublishMode = evalin('base', 'inPublish');
catch
inPublishMode = false;
end
You can now set the inPublish variable from the workspace before running your test, and wrap your optional code in conditional statements.
if inPublishMode
% do something
end
Still not perfectly satisfactory, but it's another tool in the bag.