I have enabled code coverage statistics in Xcode 7.0 and Objective C (like this) and it's working well.
Is it possible to mark some source lines so that they are ignored by the coverage report? If I was using lcov then I could use LCOV_EXCL_START and LCOV_EXCL_END markers (as in How to tell lcov to ignore lines in the source files) but Xcode doesn't recognize those.
Does Xcode have an alternative mechanism for doing this?
Xcode7 and later (based on some forum posts), the coverage system uses LLVM's coverage generation and reporting mechanisms, the format for which is detailed at http://llvm.org/docs/CoverageMappingFormat.html. As of Xcode 9, this format does not support any means of exclusion of lines (or other structures).
The resulting mapping is exported into a consumable format (txt or html) by llvm-cov, which also doesn't really have much in the way of exclusion mechanisms. llvm-cov does have some simple thresholding for only reporting on "greater than" or "less than" coverage for both lines and regions, but I suspect that's not entirely what you're after based on the question above.
Related
I've been looking to evaluate the red programming language - red-lang.org
While it is nice that you can obtain a working executable easily I prefer to compile things from source. It is less obvious how to do that for red.
The instructions ask you to download a rebol compiler/intepreter which is itself just an executable.
If you do that it works but it screams "don't do that" very loudly.
rebol> do/args %red.r "-v 2 %tests/hello.red"
will compile hello world but how do you bootstrap the red compiler itself?
1. Assuming you have rebol how do build the 'red' executable?
aside: Are the authors aware that there is a program called 'red' installed on many Linux boxes already (a version of the ancient ed program)?
I thought this might be done by:
rebol> do/args %red.r "-r %environment/console/console.red"
but "console" is not the executable also known as 'red' it doesn't support the same commmand line options such as -c to compile.
2. Assuming the proper way to do this involves bootstrapping from rebol (rather than C or something else) how do you build (a suitable) rebol from source?
I would like to build both red and red/system or any other interesting variants.
This question mentions a youtube video but is there something written down somewhere?
This seems like the sort of thing than ought to be near the front of the documentation to me.
I asked a similar question in their Google Group about a year back.
https://groups.google.com/forum/#!topic/red-lang/zZ3jEeNJ5aI
The short answer is this ...
The current “bootstrap” Red compiler is written in Rebol. Rebol is not compilable. The downloadable Red binaries are not compiled but encapsulated (containing both the compiler and a Rebol executable) using the Rebol Software Development Kit (SDK). The Rebol is SDK is a commercially licensed product that is probably not available any longer. (The REBOL SDK used by the Red team is properly licensed).
There are scripts and instructions on how to build a Red binary at https://github.com/red/red/tree/master/build
That said anything you can compile with the Red binary, you can compile with the source compiler. The source compiler is just as fast as the “binary” one. (As you know, the source compiler happily runs under free Rebol versions that are still easily available.) In fact, the red team uses the source compiler not the “binary” one.
So until the self-hosted Red compiler is available, there are two basic options:
if you want to use the Red binary, get it from the automated builds
if you want the absolute, up to the minute compiler, use it in source form.
Hope this helps.
Peter
The zinc spec says this:
If no output item is present, the implementation should print all the global variables and their values in a readable format.
However this does not appear to work with minizinc version 1.6.0:
G12 MiniZinc evaluation driver, version 1.6.0
I've tried the default command (minizinc) and mzn-gecode.
I'd really like to avoid repeating all the variable names in the output expression. What I really want is to have all decision variables output in some structured format (e.g. YAML), but I'd settle for some way to avoid this repetition.
To clarify: my model doesn't match the typical examples of CSP, e.g. there's no big array or matrix. It's just a fairly big (in relative terms) set of individual decision variables.
EDIT: bug created.
EDIT2: bug is now fixed in the minizinc 2.0 git repository so it conforms to the spec.
What I know, all FlatZinc solver just show a "----------" for every solution when there is no defined output item in the model. So it seems that the spec is wrong/obsolete on this part.
There have been some (more or less radical) changes regarding the output item during the years. In some early MiniZinc version it worked the way the spec described, and it was quite handy when modelling a problem (though it was very hard to get nice output). It was a real nuisance when the behaviour was changed so an output item was required for showing the result.
Interestingly, Zinc (the "big brother" of MiniZinc, http://www.minizinc.org/g12_www/zinc/ ) works as described i.e. shows all global variables when there is no output item. Perhaps the spec writers just forget to mention that MiniZinc differs.
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've got a bunch of ACPI Source Language files and I want to calculate file to file similarities between them. I thought of using something like Perl's Parse::RecDescent
but I am stuck at:
1) Translating the ACPI Grammar (www.acpi.info/DOWNLOADS/ACPIspec40a.pdf) to something Parse::RecDescent would understand
2) Have a metric to compare 2 parsed files
Any ideas?
To get started with Parse::RecDescent you may look at Pro Perl Parsing, Ch. 5 or
at Advanced Perl Programming, Ch. 2
Xml Diff tools should be appropriate for comparing hierarchically structured data; perhaps you can apply such a tool to ASTs saved in XML format
So you have two problems:
Parsing ACPI to build an AST. This has the usual troubles of ensuring that you have a well defined grammar, that your parsing machinery can parse according to that grammar (often you have to bend a good grammar definition to enable the parsing machiney to process it), and building a corresponding AST. You will have these troubles with Perl parsing machinery, simply because it is a parsing engine.
Comparing the structure of the ASTs and producing a sensible answer. What you are likely to find here is that there is some literature describing roughtly how to do this (using e.g. Levenshtein distance), but that the details for ASTs matter. (Change distilling: Tree differencing for fine-grained source code change extraction Finally, having determined the distance, you need to print out the deltas in some readable form.
However, AFAIK, my company is the only one that has reduced this to practice. See our Smart Differencer tool. THe SmartDifferencers parse, build ASTs, and report changers in terms of ASTs elements moved, inserted, deleted, replaced, or modifiied by consistent identifier substitition. They depend on any underlying very strong GLR parsing engine which minimized the problems of accepting new grammars. They work for many common languages but not presently for ACPI.
Is there any diff tool for Lotus Notes which allows to compare scripts, design elements and documents?
I see this is an old question, and most of the other answers are a little outdated now, so I thought I would add some hopefully valuable information for those who should stumble upon this now.
In Domino Designer, open either the Navigator or Package Explorer (Window menu -> Show Eclipse Views). Here you can expand databases/templates to see the design elements they contain. Select two or three elements (CTRL-click). They can be in different databases or the same database. Right click on one of the elements and select Compare with -> Each other.
You can also compare two databases element by element by selecting two databases/templates, right-clicking and selecting Compare with -> Each other. You will then get the differences between the two databases listed. You will be able to see which elements differ between the two databases, and which elements exist in one database but not the other. By double-clicking on a differing element, you will open a diff tool which lets you see differences line by line, and you can easily copy changes from left to right or right to left.
There is a tool from TeamStudio called Delta: http://www.teamstudio.com/products/delta.html
If all else fails (and by "all else" I mean the often ridiculous corporate procurement system) you can always do a an export to DXL (or a Design Synopsis for code alone) and use any decent text editor with a diff function. It's not TeamStudio Delta, but it will get you where you want to go.
There is a free tool from OpenNTF which does document comparisons:
http://www.openntf.org/Projects/pmt.nsf/ProjectLookup/Compare%20Notes%20Documents
Ytria also has a product which, among other things, will compare data documents (I don't believe it compares design elements).
http://www.ytria.com/website.nsf/WebPageRequest/Solutions_scanEZ_specen
And, I believe Martin Scott (http://www.martinscott.com) has a similar product which compares documents.
DDE (Domino Designer on Eclipse) let's you compare design elements natively. Same way as the search. It's pretty efficient (faster than a DXL exportation) and it's free.
I had a discussion on my blog a little while back about this:
http://rosshawkins.net/archive/2009/12/24/notesdomino-refactoringanalysis-tools.aspx
However what I've ended up doing in the past is exporting the design to the filesystem and using standard text tools (WinMerge and SublimeText for me personally) to do what I need.
Being able to do the raw dump is something that was added with the Eclipse based designer, and isn't overly obvious, but you can read more about it here:
rosshawkins.net/archive/2010/01/20/searching-the-contents-of-notesdomino-design-elements.aspx
(link mangled as my rep is too low to post 2 links in one post yet!)
Teamstudio Delta is really nice. However it might kill you with too many details. As Ross pointed out the Domino Designer 8.5 can use the Diff tool inherited from Eclipse. You also could head over to http://www.openntf.org and look for the DXLMagic project. It can generate a report that shows differences (including code) between 2 databases (typically a template and a variation of it). It is not as complete as Delta, but shows the essentials. It's free and source is included (Disclaimer: I wrote it).
This is what I do. I run a design synopsis of the database using the Notes Designer. Dump the file to a text file. You can actually split the synopsis out to different objects like Agents, Forms, Views, etc. Then you can run UNIX/Linux/Mac Unix commands to compare the elements. By doing this operation you find out what code is active, and have a complete documented source code. You do a lot of csplit and a few sed commands.
Version 12.0.1 has such a tool as part of the server. Look for comparedbs.ntf and designsynopsis.ntf on the Domino server.