Our Doxygen build in ITK is raising a number of "unbalanced grouping commands" warnings:
https://open.cdash.org/viewBuildError.php?type=1&buildid=8335387
Following the warning description I am guessing that these might be due to a potential improper use of "\ingroup" commands in our files, or the impossibility to correctly interpret them the way we define our groups.
Besides the code modules that we parse as groups, we define a number of other groups.
That give rise (using a GitHub actions workflow) to the modules shown in:
https://itk.org/Doxygen/html/modules.html
Despite the warnings, many of these filters seem to display the modules/groups they belong to correctly in the header of the file, e.g.
Data Processing Objects » FunctionsData Processing Objects » Functions » Image Functions » | Image InterpolatorsGroup Core » | Module ITKCommon
https://itk.org/Doxygen/html/classitk_1_1BSplineInterpolationWeightFunction.html
However, we would like to remove the warnings and get a clean build, so I am wondering how to fix the warnings.
We have an ITK issue that may be useful for anyone trying to help.
Thanks.
Code inspection to locate grouping commands that are not properly closed.
Related
We use DocFx in our projects. We would like to check for no problems in VSCode but we get the warning link.no-such-reference for DocFx Note formatting which uses square brackets.
Do you support suppression of problems like using:
[//]: # (<!-- markdownlint-disable line-length -->)
Could not find any documentation about suppressing one problem type once at a single code line.
I have installed the persp-mode and workspaces packages from the elpa repository. persp-mode depends on workspaces.
I was unable to get persp-mode working until the workspace.elc file was deleted. I have made a backup of this file for troubleshooting.
What could have been the cause of error?
How can I debug this problem systematically?
Without you giving us the error message it's hard to know what caused this, but generally the easiest way to debug compilation issues is to restart Emacs (so you have a fresh image), go back to the source file and recompile it with M-x emacs-lisp-byte-compile-and-load. This will show you any errors or warnings that occur when the file is compiled. Look for the following:
undefined variables and functions, which often indicate
features that have not been required by the package
simple typing errors
unexpected end of input errors, which indicate unbalanced parens
general usage errors, such as
function calls with incorrect argument counts
macro expansion errors
These sorts of issues are usually pretty easy to fix. Remember, you can always redefine the package's functions and vars yourself if they are broken.
In some code coverage tools you can "hide" certain lines of code from the coverage tool, so that those lines do not count towards the coverage totals. For example, some code might be run only in circumstances that are hard or impossible to test (such as certain hardware failures). Thus, you might get 100% coverage reported even though some code was not exercised.
Setting aside for the moment whether this is wise, is this sort of thing possible with Perl's Devel::Cover?
(Devel::Cover can ignore entire files, but I am interested in ignoring just a few lines in a single file.)
A lot of uncoverable code features have been implemented but they are not documented because I wasn't sure of the interface. However, it's been a few years since anything changed in that area.
Probably the easiest way to see how to use the features is to look at tests/uncoverable in the distribution (see https://github.com/pjcj/Devel--Cover/blob/master/test/uncoverable). If you can't or don't want to change your code you can use the .uncoverable file (see https://github.com/pjcj/Devel--Cover/blob/master/tests/.uncoverable) and the cover options as mentioned by toolic.
If you do this, be sure to use the basic_html report which will mark a construct as in error if you tag it as uncoverable but it gets executed anyway.
I really should get around to tidying everything up and documenting it.
According to the TODO file on CPAN, this capability is not currently supported, but the developers see it as a valuable addition:
Enhancements:
Marking of unreachable code - commandline tool and gui.
The cover script mentions promising options: -add_uncoverable_point and -delete_uncoverable_point.
I am debugging my program with apache mina 2.0.2. The specific library is irrelevant.
The problem is that Eclipse can see internal structure of some classes and cannot see one of the others. No apparent differences visible for me: both classes have both code and source.
You can see that Eclipse draws arrow near AbstractPollingConnector class and does not so near AbstractPollingProcessor.
Of course Eclipse can't set line breakpoints inside "bad" classes.
What is the reason of it and what to do?
I guess, it depends whether the referenced classes were compiled with the debugger options on or off. According an older Javac manual, the -g switch seems related:
-g
Generate all debugging information, including local variables. By default, only line number and >source file information is generated.
-g:none
Do not generate any debugging information.
-g:{keyword list}
Generate only some kinds of debugging information, specified by a comma separated list of >keywords. Valid keywords are:
source
Source file debugging information
lines
Line number debugging information
vars
Local variable debugging information
Is there a way from WinDbg, without using the DbgEng API, to display the symbol server paths (i.e. PdbSig70 and PdbAge) for all loaded modules?
I know that
lml
does this for the modules whose symbols have loaded. I would like to know these paths for the symbols that did not load so as to diagnose the problem. Anyone know if this is possible without having to utilize the DbgEng API?
edited:
I also realize that you can use
!sym noisy
to get error messages about symbols loading. While this does have helpful output it is interleaved with other output that I want and is not simple and clear like 'lml'
!sym noisy and !sym quiet can turn on additional output for symbol loading, i.e.:
!sym noisy
.reload <dll>
X <some symbol in that DLL to cause a load>
!sym quiet
When the debugger attempts to load the PDB you will see every path that it tries to load and if PDB's weren't found or were rejected.
To my knowledge there's no ready solution in windbg.
Your options would be to either write a nifty script or an extension dependent on where you're the fittest.
It is pretty doable within windbg as a script. The information you're after is described in the PE debug directory.
Here's a link to the c++ sample code that goes into detail on extracting useful information (like the name of the symbol file in your case). Adapting it to windbg script should be no sweat.
Here's another useful pointer with tons of information on automating windbg. In particular, it talks about ways of passing arguments to windbg scripts (which is useful in your case as well, to have a common debug info extraction code which you can invoke from within the loaded modules iteration loop).
You can use the command
lme
to show the modules that did not have any symbols loaded.
http://ntcoder.com/bab/tag/lme/