I'm currently trying to use the PlUnit test suit and encounter a problem to turn off the output of my predicates during the test.
The documentation says that I should be fine with something along the lines of set_test_options([silent(true)])., however that doesn't seem to have any effect on my test runs.
I tried to put those options into my load_test_files/1 call as well, but it didn't change anything.
If anyone can provide help about this library that'll be gratefully read, as I seem to misunderstand the documentation and am getting nowhere when trying to see what fails here.
Related
(I've looked far and wide but I can't even find anyone having the same problem, not to mention a fix or anything. Closest is this thread which just announces the feature...)
The way it currently works for me, the VS2019 code lens integration of P4VS (for C++ at least) is almost completely pointless. Each function has an indicator added, but the information in each is identical - namely the change history of the entire file:
According to this Microsoft article, I would expect to either get function-level change information that pertains only to that function or a single change summary of the file at the bottom of the editor. But instead I get the worst combination of both.
I'm mainly surprised that I can't find anyone else talking about this, so I assume something is misconfigured on my part. Can't find anything in the configuration options though...
Is this just a bad implementation by Perforce or is something wrong on my end?
I have just found out that it can be turned off by Visual Studio options.
How to turn off CodeLens-References
Text Editor > All Languagues > CodeLens
Currently VS Code will only highlight errors when the file is saved. This can get bothersome, as it isn't immediately apparent sometimes if you've mistyped something or are using something wrong etc.
Is there a way to make VS Code automatically show syntax/logical errors i.e red/green squiggles underneath code?
I am working with python but I have the same problem.
As shown here: "Linting runs automatically when you save a file."
Therefore, what I did to automatically lint, is enable Auto Save. With this configuration you can achieve linting almost in real time.
I guess that for C++ will work similar. Hope it helps.
I try to run a cppcheck analysis over my code, which has the following file structure:
/code/module_1/src/a.cpp
/code/module_1/src/b.cpp
/code/module_1/test/c.cpp
/code/module_2/src/d.cpp
/code/module_2/src/e.cpp
/code/module_3/test/f.cpp
I'd like to run an analysis excluding all test code. Is this possible with a command like "cppcheck -itest"? It doesn't work for me, although I think it should, according to the docs:
...Directory name is matched to all parts of the path.
I'm using version 1.69. I know I could mention all test directories separately (which does work, I checked), but the number of modules is too high to do this for many analyses reasonably.
Is this possible?
I installed Cppcheck to do some tests and it seems the -i implementation is a bit bonkers. However, I managed to achieve what you want.
Solution: use -itest\ instead of -itest (this was in Windows; maybe Linux needs -itest/)
Rationale: in my tests, -itest worked only if there was a .\test\ directory, in which case even .\a\test\a.cpp was excluded. With -itest\, however, such exclusion took place regardless of the presence of .\test\ directory.
This seems like a bug which the developers ought to weed out, but, in the meantime, you can succeed using the above workaround.
This is a late response to an old question, but perhaps this will help other latecomers like myself.
Disclaimer: This answer is for Windows.
It seems as if v1.79 has remedied the OP's issue. The following command line syntax has worked for me:
cppcheck -itest code
In this example, "-itest" weeds out any occurrence of the "test" directory, as originally (and correctly) assumed by the OP. In addition, the code folder is found next to the cppcheck.exe. This will be the root of the recursive source-code scan.
I'd use something like:
cppcheck /code/module_1/src /code/module_2/src /code/module_3/src
I am using PC-Lint for my C++ project.
Is there a way to switch off all error and warning messages by default, so I can then reintroduce the required messages explicitly?
I have read the chapter of the PC-Lint manual entitled "Error Inhibition Options" and the best I could find was setting the wLevel to -w0 No messages (except for fatal errors)
Yes, it is possible, you can simply use -e* or -w0. However, the manual truly states (Chapter 16. Living with Lint):
DO NOT simply suppress all warnings with something
like: -e* or -w0 as this can disguise hard errors and make subsequent diagnosis very difficult.
So, yes, you can use it if your code is basically cleaned, and you want to review recent changes for a certain set of messages. But if you want to start cleaning your code, and are swamped with messages because of the default warning level -w3, I suggest to start using -w1, and resolve all issues there; most of the warnings/errors given at level one indicate problems with finding all header files, having al implicit macros set properly, and/or mimicking the compiler you use normally in a sufficiently precise way.
As always, I hesitate to advertise my own work, but if you want, take a look at my "How to wield PC Lint" PDF, where I have documented detailed instructions to handle the initial deployment of PC Lint and tackling the many warnings/errors/infos/notes you may be buried under.
When I started introducing PC-Lint to a new project I did the following:
As suggested by Johan Bezem, ran a -w1 level check over the whole thing. This doesn't actually find any new problems, but checks that your program is syntactically valid and finds any configuration issues. Nothing major, assuming your project compiles already.
Run the test again with -w2 level. This found 53,000 issues, which was a bit much to tackle in one go.
Pick a typical bad file, then suppress any errors that seem
irrelevant or non-urgent (eg. error 525: (Warning -- Negative indentation from line xxx)
adding -e525 to the command line or config file, until you find one that seems serious.
In my case this was
error 442: (Warning -- for clause irregularity: testing direction inconsistent with increment direction), i.e. a 'for' loop
that looked like it should be counting up was actually counting
down.
Reset the test level back to -w1 but added in the critical problem by number, -w1 +e442 in this case. Re-run it over the whole project then fix all the instances of that problem.
Back to stage 2 and try again.
This combination of fixing actual problems and suppressing likely false alarms soon gets your numbers under control.
So that everything gets better over time we also implement a script that does a thorough (full -w2 or -w3) check on any files that are created or modified.
I also found the tool LintProject very helpful as it can do an entire Visual Studio solution in one go, with tables with numbers of errors and worst offenders!
I just downloaded this code in which it says in the manual that the 'main results are directed to standard output (cout)'. However, when I run the code as described in the manual, everything runs just fine but I don't see any results showing on the terminal (not being written to an output file either)
This is a Linux code so I tried to run it form both Ubuntu terminal and from cygwin but I'm having the same problem - nothing is showing.
Could it be that 'the main results are directed to a standard output (cout)' means anything else? Other that it's supposed to show the results on the terminal?
There's no other meaning that I can think of for "standard output (cout)" - it should be the terminal that's running the program. Are you sure the program produces output?
Unless you have the source code, it's a little difficult for you (or us) to tell if it may have another meaning ("directed to standard output (cout)" is a little hard to misinterpret however, there's no other sane reading of that snippet).
If you do have the source, you can look for the cout <<-type statements to ensure something is done. You may have to examine the logic closely to see why nothing is being output for your specific case.
If you can share the source with us, we could help out further but it doesn't appear you're comfortable with that so the "analyse the code yourself" is probably the best answer you'll get.
Of course, there's always the option of going back to the author if your analysis is not going well, or if you don't have the source.
Ensure that there is no "wrapper" script encapsulating the program, which is internally redirecting the standard output to a file.