I'm just getting started with using grunt and I've installed grunt-include-replace
Now it does say quite clearly;
WARNING: The task does not check for recursive includes.
But does anyone know of a hacky way around this?
I've tried a number of things but not got anything working yet.
Any ideas?
I suggest you use https://github.com/vanetix/grunt-includes instead.
I had the same problem, and although the config is a bit different and the default include syntax is different include "_includefile.html" and it does not support variables and globals as far as I know. It solves the recursion problem.
This warning is misleading
The WARNING: The task does not check for recursive includes is actually referring to the script not checking for circular includes. It's warning that the plugin will not check for potential infinite loops, e.g.
Where file 1 includes file 2 and file 2 includes file 1.
I very nearly went looking for another plugin for the same reason, but after trying it out, this plugin definitely does work with recursive includes, e.g.
Where file 1 includes file 2 and file 2 includes file 3.
Related
Stata's swilk command performs the Shapiro-Wilk test for non-normality. Likewise, Stata's sfrancia performs the Shapiro-Francia test for non-normality. However, both commands share the same help file swilk.sthlp.
How does Stata know that a single help file serves for more than one command? For example, how does Stata know that swilk.sthlp holds the correct response to the command help sfrancia? Or that ttest.sthlp holds the correct response for help ttesti (not just help ttest)?
I am writing a new package for which the same help file should similarly serve for more than one command, and want to be sure I get it right.
StataCorp's own signposting pointing a call for help elsewhere is in recent versions typically done by .maint files. Thus
viewsource shelp_alias.maint
contains a list of various pointers from names starting with s, including allowed abbreviations, and help sfrancia can be seen to fire up help swilk. For s substitute any other pertinent initial letter.
To see where such a file lurks on your system, use which
which shelp_alias.maint
The historic system and one that is easy for user-programmers to emulate is that a help file which is named foo.sthlp and contains the single line
.h bar
is equivalent to a direct help bar. So if you type
. help foo
it is exactly as if you had known to type
. help bar
This system predate the introduction of SMCL and no SMCL directives are to be used.
In summary: a file such as foo.sthlp simply points at bar.sthlp and is not a complete help file.
More on .maint files: Essentially user-programmers should ignore them as far as their own packages are concerned. Otherwise every user would be committed to editing the .maint file concerned on every system they used, which might not even be allowed locally, and to doing that on each upgrade of Stata. Further, StataCorp might use some different system in future versions. In contrast, the .h mechanism has been used for so long and been publicised so much that it is safe to bet that it will work indefinitely.
Note: Stata help files were originally labelled with the extension .hlp. When Stata was started in 1985, compatibility with the existing DOS rule that file extensions could not exceed 3 characters in length was vital. Later Windows adopted precisely the same extension for its help files, and given such force majeure Stata introduced .sthlp files in version 10. Stata can naturally still read .hlp files that are text files in appropriate directories or folder, i.e. along the defined adopath.
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 wanted to know if anyone have used UniversalindentGUI.
I am trying to use and when run it get the following error.
There is no proper documentation or tutorial how to use it, if any one have used it please help me.
Indenter returned with exit code: 1
Indent console output was:
(STDOUT):
(STDERR):Cannot find file indentinput.cpp
Callstring was:
"/Users/rbang/Desktop/Tools/UniversalIndentGUI_macx/indenters/astyle"
indentinput.cpp
--options="/Users/rbang/Desktop/Tools/UniversalIndentGUI_macx/temp/.astylerc"
Open up indenters/uigui_astyle.ini in the directory where UniversalIndentGUI is installed and find the following properties:
inputFileName=indentinput
inputFileParameter=
outputFileName=indentinput
outputFileParameter=none
Change them to:
inputFileName=
inputFileParameter=stdin
outputFileName=
outputFileParameter=stdout
Voila!
I experienced the same problem, however if you switch to a different indenter in the pull down menu at the top of the ui(just below the text "Indenter Settings" and use a different indenter(i am using Uncrustify(C, C++, C#, Objective-C) it functions. I suspect it has to do with the fact that all the indenters may not be bundled with the download BUT uncrustify is. Most of the ones I tried have this issue, but the only one I care about is uncrustify.
I would like to set a break point on file modification for a particular file, or on opening a particular file. This is a file which our software opens and modifies during portions of legacy code. I'm not exactly sure how to approach this problem. One approach I have thought about was to find all of the places where we are opening files, break on all of them, and inspect the file path to determine if it is the path we are concerned with. The other approach I was thinking was to attempt to set a break point in the file system opening code when the path matches what I am concerned with (possibly more difficult, as I am presently running under Windows. This might be an option under Linux but a Visual Studio 2005 solution would be ideal and a Linux solution potentially useful).
Presently, I am using Visual Studio 2005 for my software project in C++. I was not able to find anything online about this as an option or an approach people would like to take.
Normally, I would say that I should just understand where this file is being opened. Unfortunately this section of code is quite difficult to understand and will be re-factored, but for the immediate future this functionality would help me.
Thank you very much for reading my question,
-Brian J. Stinar-
Put conditional breakpoint to kernel32.CreateFileW and check file name.
Then you will get file handle, so you can put conditional breakpoint to kernel32.CreateFileW and check file handle.
Also you can hook CreateFileW and call __debugbreak() in it.
Hello! I am updating some C code that copys files with a certain name. basically, I have a directory with a bunch of files named like so:
AAAAA.1.XYZ
AAAAA.2.ZYX
AAAAA.3.YZX
BBBBB.1.XYZ
BBBBB.2.ZYX
Now, In the old code, they just used a call to ShellExecute and used xcopy.exe. to get all the files starting with AAAAA, they just gave xcopy the name of the file as AAAAA.* and it knew to copy all of the files starting with AAAAA. now, im trying to get it to copy with out having to use the command line, and I am running into trouble. I was hoping CopyFile would be smart enough to handle AAAAA.* as the file to be copied, but it doesnt at all do what xcopy did. So, any Ideas on how to do this without the external call to xcopy.exe?
Check this out as a starting point
http://msdn.microsoft.com/en-us/library/aa364418(VS.85).aspx
or even better this full example
http://msdn.microsoft.com/en-us/library/aa365200(v=VS.85).aspx
You could also use SHFileOperation or IFileOperation (the latter being only available from Vista upwards but is now the recommended way according to MSDN). SHFileOperation supports wildcards and displays a progress by default, but there's also a flag for silent operation.
Check out the following MSDN links for more info:
http://msdn.microsoft.com/en-us/library/bb762164(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb775771(v=VS.85).aspx
You would basically have to write code to reproduce the functionality in xcopy. To do so, you must build a list of files by accessing the path and recursing through it. Test each found entry with your pattern and keep only those that match. Then iterate over that list with CopyFile.
See the following set of functions that can help you build the file list:
http://en.wikipedia.org/wiki/Dirent.h
It might just be easier to keep using xcopy unless you have a specific reason not to.
There are lots of ways to do it. I'd probably use a loop of FindFirstFile() / FindNextFile().
However, is there any reason you can't still use xcopy? You can launch it with CreateProcess(). It isn't pretty, but it works.