In my JS library I've noticed that none of the files starting with an underscore are appearing in my output from JSDoc3. These are marked using #module and I've tried adding #public and also building with the -p switch but I can't seem to get them appearing. Any ideas how to solve this?
I've discovered that if you run JSDoc using a configuration file (http://usejsdoc.org/about-configuring-jsdoc.html#configuration-file-command-line) you can update the excludePattern which by default includes files starting with the underscore pattern.
Related
I have a bunch of files with filenames like Matroid (bifrons's conflicted copy 2019-11-19).scala due to problems of synchronization. I want to find this files to remove or manually correct the problems (merge the two versions of the file). I tried the command below:
$ find . -iname '*conflicted*'
But it returns nothing! Nada!
I am guessing this is because the word conflicted occurs inside parentheses, but this is just a conjecture. Anyway, why my command do not find the files? How can I find them?
Thanks.
Actually the problem had nothing to do with parentheses at all. It as a (silly) mistake of mine. The directory containing the files with the *conflicted* filename was actually a link and find does not follow links by default. After informing the option -L it worked perfectly.
I use swiftlint in my project. The project name is ABC xx and it works fine with swiftlint. Now I decided to include Unitest in my application and I have to import #testable import ABC_xx into the swift test file which is class ABC_xxTests: XCTestCase { not I get an error with Swiftlinter which says Type Name Violation: Type name should only contain alphanumeric characters: 'ABC_xxTests' (type_name) how do I sort this error
The following swiftlint rule enable the use of underscore in your Swift class names:
type_name:
allowed_symbols: "_"
EDIT:
If you want to enable the use of underscore also for variable names use:
identifier_name:
allowed_symbols: "_"
In addition to #carmine's answer, keep the below two things in mind while adding attributes to any rule in .swiftlint.yml:
it should be listed in a new line
and should be preceded with a white space.
In my case I overlooked the white space before allowed_symbols. So the linting was not working. When I added white space, it was successful.
You can disable rule for specified folder, in your case its an ABC_xxTests folder. Inside .swiftlint.yml configuration file you can use 'excluded' property. If you haven't yet create swiftlint configuration file, you can create one with name .swiftlint.yml and place it in your project root folder.
Add this lines:
excluded:
- ABC_xxTests
Use of underscore for variable names add in .swiftlint.yml:
variable_name:
allowed_symbols: "_"
I am trying to separate out internal and external documentation using the doxygen constructs of cond; but i just cant seem to get get it working. I would essentially like to exclude some files completely and not conditionally. Regardless of where i add the tag (before include, before header guards etc) , the files and source both show up.
What i have tried in vain is to take the test file from doxegen repo for
conditional test and add it to the project.
Steps to reproduce [Linux]
create a new directory.
copy paste the above file (had to rename it to .h as .c was passed over?).
generate dummy config via doxygen -g.
update Doxyfile ENABLED_SECTION = COND_ENABLED.
Run doxygen.
check html/index.html
This however is still visible in the html documentation it generates for the project. I have set the ENABLED_SECTION variable with other values , but cond_enabled function still shows up. Running the testing directory of the project (doxygen) it passes. So i am lost.
Any suggestions?
Tried with latest version 1.8.14.
Thanks!
Regarding the \cond problems (not an answer directly to the real problem you face, I think, but to long for a comment).
The mentioned file is used in the, limited, testing doxygen can do / does and the first lines contain some instructions on what to do. Furthermore there is a default Doxyfile with the tests in use. It is hard to run a separate test outside the doxygen build tree.
Regarding the remark "Running the testing directory of the project (doxygen) it passes." This is correct, here, at the moment, only testing is done against the XML output and the generated output is compared to a once created version of the XML output. No tests are done, at the moment, in respect to HTML or PDF / LaTeX. Recently the test framework has been slightly extended so in the future this should be possible (compare the xhtml and tex output, but some work has still to be done here).
The version of the parser sees the \cond in the first line (normal C comment) as a doxygen command and skips everything till the first \endcond (your friend in these cases is always doxygen -d preprocessor). I think that removing / modifying the first line will result in an already better result. There is however another hiccup for e.g. HTML output. As the function cond_enabled is not documented and EXPAND_ALL is not set to YES the function will not appear in the documentation. So best is also to add a line of documentation with the function cond_enabled.
Regarding the seen HTML problems I modified the the relevant test in doxygen slightly and pushed a proposed patch to github (pull request 714, https://github.com/doxygen/doxygen/pull/714).
Note: the problem of skipping the \cond in normal C comment is quite a bit harder to implement (seen the logical complexity of the doxygen code in pre.l and commentcnv.l.
EDIT: 2018/06/10: The push request has been integrated in the master version on github.
So for various "boring" reasons, I'm stuck using VC++ 2008.
Now, I have a custom build rule that parses a ".h" file and produces a .cpp.
The build rule works fine when I can get the setting in the .vcproj (it appears as a <Tool Name="my rule"/> element as a child of the <FileConfiguration> elements for each <File> element).
In the ".rule" file, the FileExtension attribute I've specified is "*.hxx" and not "*.h" as I don't want the custom rule running on every .h, only the ones I want it to. Changing the extension of the files to run the rule on to something other than .h is not an option for reasons that are beyond my control.
The rule works fine, the generated .cpp gets compiled, the dependencies etc are all working - i.e. VC++ only does the custom step when the .h changes etc.
Manually hacking the xml in the .vcproj gets thing working, the issue is the Visual Studio GUI keeps messing with the tool setting and deleting it from the ".vcproj". I haven't definitively determined exactly under what conditions Visual Studio mucks up the setting, as it's somewhat random, but mostly when any change to the project needs to be saved is my observation.
Sometimes (not always) I can manually change the tool in the properties page in the visual studio GUI and it will save it for the active configuration (e.g. "Debug"), but when I try to add it to other configurations (e.g. "Release" or "All configurations") the GUI gets confused and deletes the tool setting for all configurations instead of adding it for the other configuration.
This seems to happen also if I first change the active configuration -> when you go to set the custom tool it gets confused and deletes the setting from all configurations.
I've been able to get similar rules working fine when the input file for the custom rule has a unique extension, it seems to be related to the input name matching ".h" and the default rule for .h's and that my ".rule" file doesn't specify a corresponding matching pattern.
Note this setup with the non matching FileExtension pattern is what was recommended on MSDN for VC++ 2008, which is why I did it that way.
Anybody had any similar issues ? Any clues at all on what a robust solution and/or workaround might be ?
I just need to preserve the setting in the context that NOOBS might be using the VS GUI so you can't trust them to not do "certain things".
OK, so after much searching here, and anywhere else I could think of, and trying a bunch of dastardly incantations I've still got no joy on an actual solution to the problem of preventing the IDE deleting the custom build tool setting when the extension pattern doesn't match the file.
So the work around was I changed the rule to use "*.h" pattern and do a test to see if the custom command needs to be run. The following is my "FunkyRule.rules" file in case anybody needs to see what I did:
<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="Funky code generator"
Version="8.00"
>
<Rules>
<CustomBuildRule
Name="Funky"
DisplayName="Funky code generator"
CommandLine="IF NOT EXIST $(InputFileName) goto :notFound
NeedsFunky $(InputFileName) 1>nul || goto :notFound
echo Generating Funky things for $(InputFileName)
FunkyCodeGenerator $(InputFileName) -o ".\GeneratedFiles\funky_$(InputName).cpp "
goto :done
:notFound
exit 0
:done
"
Outputs=".\GeneratedFiles\funky_$(InputName).cpp"
AdditionalDependencies="$(InputFileName)"
FileExtensions="*.h"
ShowOnlyRuleProperties="false"
>
<Properties>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>
This CustomBuildRule needs two external commands "NeedsFunky" and "FunkyCodeGenerator".
"NeedsFunky" is a command that returns 0 if the input .h is a valid input for "FunkyCodeGenerator" and non-zero otherwise.
"FunkyCodeGenerator" is the command that does the "funky-ness" taking the input .h as a parameter and requiring a -o option to specify the output file.
In this context (i.e. whatever environmemt Visual Studio calls the resulting temporary .bat file), I had some trouble making an IF statement work using the usual "IF errorlevel" syntax, so hence the unusual "cmd || goto :failLabel" construct.
If you add this rules file to the custom build rules for a project you'll automatically get "some funkiness" on all your ".h" files :-)
I'm having trouble forcing the CoffeeScript compiler to add a source map url comment to the end of file.
I attempted to use: coffee -mo script/lib -cw scripts/src
This command creates a source map, but doesn't always add the appropriate comment to file. Therefore Chrome cannot find the source map and I'm unable to see the associated CoffeeScript.
I also tried passing the --bare option to no avail.
Unfortunately, inline source maps are not possible with coffee
Take a look at this command line utility that will do it for you though: https://github.com/gromnitsky/coffee-inline-map
I found that coffee doesn't the comment while watching for changes. If stop it and then compile changes once the comment appears.