IOS project code coverage source file is relative path - ios

I have generated .gcno and .gcda files after running my iphone app.Then I use cover story to view the coverage rate.However, cover story could not open the source file and I found that the source path is a relative path, not full path.All I can see is full of /EOF/ in the screen.
The strange to me is that only some of the files could not open due to this path issue. Most of them are full path and cover story can open them successfully.Unable to attach screenshot
How can I show the correct path names in CoverStory?

I suggest generating an HTML report with lcov, which allos you to normalize the directory names.
Other benefits of using an HTML report are:
The coverage information is available on both desktop machines as well as from a Continuous Integration build server.
To install lcov
Use Homebrew or MacPorts
Example:
brew install lcov
First Generate Datafile
#!/bin/bash
set -e # fail script if any commands fail
${gen.info} ${temp.dir}/coverage-data/*.gcno --no-recursion --output-filename \
${temp.dir}/${module.name}-temp.info
#Remove symbols we're not interested in.
${lcov} -r ${temp.dir}/${module.name}-temp.info > ${temp.dir}/${module.name}.info
Now Generate the HTML Report
#!/bin/bash
set -e # fail script if any commands fail
${gen.html} --no-function-coverage --no-branch-coverage -o ${coverage.reports.dir} \
--prefix ${basedir} ${temp.dir}/${module.name}.info
If you're interested, I have an build script the produces HTML reports here. An example report: http://jasperblues.github.io/Typhoon/coverage/index.html

Related

Using lcov with gcc-8

I am trying to determine my testcoverage. To do this I compile my program with a newer version of gcc:
CC=/usr/local/gcc8/bin/gcc FC=/usr/local/gcc8/bin/gfortran ./configure.sh -external cmake -d
After compiling this with the --coverage option I run my tests and this creates *.gcda, *.gcno and *.o.provides.build files. And if I run something like:
> $ /usr/local/gcc8/bin/gcov slab_dim.f90.gcda [±develop ●]
File '/Local/tmp/fleur/cdn/slab_dim.f90'
Lines executed:0.00% of 17
Creating 'slab_dim.f90.gcov'
Which shows me, that gcov runs fine. However if I try to run lcov on these results:
lcov -t "result" -o ex_test.info -c -d CMakeFiles/
I get error messages like these for every file:
Processing fleur.dir/hybrid/gen_wavf.F90.gcda
/Local/tmp/fleur/build.debug/CMakeFiles/fleur.dir/hybrid/gen_wavf.F90.gcno:version 'A82*', prefer '408R'
/Local/tmp/fleur/build.debug/CMakeFiles/fleur.dir/hybrid/gen_wavf.F90.gcno:no functions found
geninfo: WARNING: gcov did not create any files for /Local/tmp/fleur/build.debug/CMakeFiles/fleur.dir/hybrid/gen_wavf.F90.gcda!
This is the same error message I get when I use the systems standard /usr/bin/gcov
This leads me to believe that lcov calls the old gcov rather than the new one. How do I force gcov to use the new version?
The simplest solution I found was to run /usr/bin/gcov-8 instead of /usr/bin/gcov.
The $PATH environment variable needs to be to extended by /usr/local/gcc8/bin/
The source of the error is clear, from the fact that you get the same result by using /usr/bin/gcov. /usr/bin/gcov should be a link to a binary from the installed compiler, but in your case the link doesn't point to a binary within gcc 8.2 installation.
You can delete the link and re-create it to point to the correct gcov or you can setup something like update-alternatives to change the version of gcov when you change the default compiler.
The previous answer should work as well if you have a binary called gcov in /usr/local/gcc8/bin, because if you add that path, into your environment PATH first, it will be selected first.

Google Cloud Platform - Viewing downloaded files after wget

I am completing this tutorial and am at the part where you download the code for the tutorial. The request we send to Github is:
wget https://github.com/GoogleCloudPlatform/cloudml-samples/archive/master.zip
I understand that this downloads archive to GCP, and I can see the files in the Cloud shell, but is there a way to see the files through the Google Console GUI? I would like to browse the files I have downloaded to understand their structure better.
By clicking on the pencil icon on the top right corner, the Cloud Shell Code editor will pop.
Quoting the documentation:
"The built-in code editor is based on Orion. You can use the code
editor to browse file directories as well as view and edit files, with
continued access to the Cloud Shell. The code editor is available by
default with every Cloud Shell instance."
You can find more info here: https://cloud.google.com/shell/docs/features#code_editor
If you prefer to use the command line to view files, you can install and run the tree Unix CLI command 1 and run it in Cloud Shell to list contents of directories in a tree-like format.
install tree => $ sudo apt-get install tree
run it => $ tree ./ -h --filelimit 4
-h will show human readable size of files/directories
and you can use --filelimit to set the maximum number of directories to descent within the list.
Use $ man tree to see the available parameters for the command, or check the man online documentation here: https://linux.die.net/man/1/tree

Error using the 'find' command to generate a collection file on opencv

I am facing a problem generating a collection file of the positive images to train the Haar Cascade in OpenCV to detect a car. On every tutorial I found on the internet, it is the same command, however i am unable to execute it.
I am using Command Prompt and Windows Power Shell to execute this command. find ./positive_images/ -iname '.*pgm' > positives.txt the screenshot of the output I am running this command from root of my directory. The positive images are stored in positive_images folder.
OUTPUT:
File not found - '*pgm'
However, the positive_images directory contains 550 files with .pgm extension.
Error File not found - '*pgm'
I am using Command Prompt and Windows Power Shell to execute this command:
find ./positive_images/ -iname '.*pgm' > positives.txt
The above command is using the syntax of a Unix version of find, but you are running it under Windows. PowerShell does not have a built in find command so you are running C:\Windows\System32\find.exe.
Notes:
Unix find is used to search for files.
Windows find is used to search for string in files.
As you are running on Windows you need to use dir instead of find:
dir /b /s positive_images\*.pgm > positives.txt
Further Reading
An A-Z Index of the Windows CMD command line - An excellent reference for all things Windows cmd line related.
dir - Display a list of files and subfolders.
find - Search for a text string in a file & display all the lines where it is found.

Installing Documentation fails

I followed the instructions for installing the documentation from the source build (by compiling the documentation scheme in CorePlotExamples) but it fails when trying to compile the documentation with the following errors.
3068: protocol_c_p_t_bar_plot_data_source-p.html
3069: protocol_c_p_t_scatter_plot_data_source-p.html
3070: _c_p_t_utilities_8m.html#a794f89cd14d4cfb21bf8c050b2df8237
3071: category_c_p_t_layer_07_c_p_t_platform_specific_layer_extensions_08.html
3072: interface_c_p_t_line_style.html#a4013bcb6c2e1af2e37cfabd7d8222320
3073: _c_p_t_utilities_8h.html#ae826ae8e3f55a0aa794ac2e699254cad
Loading symbols from /Users/GeoffCoopeMP/Downloads/core-plot-master-3/framework/CorePlotDocs.docset/html/com.CorePlot.Framework.docset/Contents/Resources/Tokens.xml
1000 tokens processed...
2000 tokens processed...**strong text**
3000 tokens processed...
4000 tokens processed...
5000 tokens processed...
* 5145 tokens processed ( 1.8 sec)
* 20 tokens ignored
Linking up related token references
Sorting tokens
rm -f com.CorePlot.Framework.docset/Contents/Resources/Documents/Nodes.xml
rm -f com.CorePlot.Framework.docset/Contents/Resources/Documents/Info.plist
rm -f com.CorePlot.Framework.docset/Contents/Resources/Documents/Makefile
rm -f com.CorePlot.Framework.docset/Contents/Resources/Nodes.xml
rm -f com.CorePlot.Framework.docset/Contents/Resources/Tokens.xml
mkdir -p ~/Library/Developer/Shared/Documentation/DocSets
cp -R com.CorePlot.Framework.docset ~/Library/Developer/Shared/Documentation/DocSets
cp: /Users/GeoffCoopeMP/Library/Developer/Shared/Documentation/DocSets/com.CorePlot.Framework.docset: Not a directory
make: *** [install] Error 1
find: /Users/GeoffCoopeMP/Library/Developer/Shared/Documentation/DocSets/com.CorePlot.Framework.docset/Contents/: Not a directory
false
Showing first 200 notices only
Command /bin/sh emitted errors but did not return a nonzero exit code to indicate failure
I found the com.CorePlot.Framework.docset files (7kb) but noticed the KIND is "Unix executable file" rather than the expected "Documention Set" like other Xcode help files.
The dockset files are also 7kb in the zip file download under the documentation folder and the kind is shown as Unix executable file there too.
Under my user Library folder I can see the dockets as in:
I also noticed that the docksets can be within the Xcode.app contents but placing these files here didn't work either.
So, is this 7k file the right one? should it be kind Documentation Set rather than Unix Exectuable File? Why does the documentation not compile in Xcode but still generates the files?
I am using Xcode version 5.1.1, Doxygen 1.8.7, graphviz 2.36 and Core Plot 2.0 source from github.
Any help would be much appreciated as I am trying to learn how to use this excellent SDK.
The Core Plot docsets should each be around 70 MB in size. A "docset" is a package which is a special type of folder treated as a single file in the Finder. When building Core Plot documentation, Doxygen makes the docset folder inside the Core Plot "framework" folder and copies it to your library from there.
Did the docset get built in the "framework" folder? Are there any aliases or file links in the path to the Core Plot folder that might be confusing Doxygen or the cp command?

Is there a way to focus lcov code coverage reports to just one or two directories?

I recently started using lcov to visualize my code coverage. It's a great tool.
One thing I'm noticing is that it generates code coverage reports for all the files that I'm using - including those that I'm not interested in. For example, it will give me code coverage reports for boost and mysql++ files.
Is there an easy way to force lcov to only generate coverage reports for specific files?
I have tried using the -k parameter like so:
/usr/bin/lcov -q -c -i -b . -d .obj -k src/ -k include/ -o app_base.info
{run unit tests now}
/usr/bin/lcov -q -c -b . -d .obj -k src/ -k include/ -o app_test.info
/usr/bin/lcov -q -a app_base.info -a app_test.info -o app_total.info
/usr/bin/genhtml -q -o lcov_output_directory app_total.info
(Meaning that I only want coverage files for the "include" and "src" directories.)
However, this doesn't seem to work. The report still shows me all the extraneous files. Any suggestions are very much appreciated. Thanks!
I used the --no-external flag together with the --directory flag to exclude unwanted files.
The definition of external from the man:
External source files are files which are not located in one of the directories specified by --directory or --base-directory.
So my command looked like this:
$ lcov --directory src -c -o report.info --no-external
Capturing coverage data from src
Found gcov version: 4.2.1
Scanning src for .gcda files ...
Found 4 data files in src
Processing src/C####.gcda
ignoring data for external file /usr/include/c++/4.2.1/bits/allocator.h
lcov supports a command line argument --remove to do exactly what you are asking for.
A possible approach is to constrain which files are compiled with the coverage flags (-fprofile-arcs -ftest-coverage). If you don't want to engineer your make file system to be selective about which files are built with test instrumentation, the following trick might work for you:
Build your application without instrumentation.
Remove the .o files for source that you want to instrument
Turn on instrumentation and rebuild. Only the deleted object files will be rebuilt with instrumentation.
Run lcov
This should result in only the targeted areas emitting gcov artifacts, which are blindly consumed by the lcov scripts.

Resources