I find the following:
http://www.yoctoproject.org/docs/2.1/bitbake-user-manual/bitbake-user-manual.html#accessing-datastore-variables-using-python
It said that: Using "expand=True" expands the value. What does the "expand" means?
Great that you are reading BitBake user manual, it helps a lot in understanding the recipe syntax.
Returning to your question the 'expand' means that in case when this particular variable value depends on some other variables, e.g:
B = "architecture_${A}"
and A is equal to "x86", calling:
d.getVar("B", expand=True)
will return you: "architecture_x86" as the variable A has been expanded.
Some other examples can be found in BitBake User Manual Chapter 3.
Related
During reading LLVM source code, I find something different in comments, e.g.
/// If \p DebugLogging is true, we'll log our progress to llvm::dbgs().
What does \p means here?
LLVM uses Doxygen for generating documentation, the /// marker is one of the many ways of creating a special comment block that Doxygen will parse to form documentation.
Within a special comment block, \p is simply one of the mark-up commands, this particular one renders the following word in typewriter font (fixed rather than proportional). The \c option is an alias for the same thing.
3 slashes is one of the ways that doxygen comments are identified.
The \p tag has some meaning, see it's documentation: https://www.doxygen.nl/manual/commands.html#cmdp
Displays the parameter using a typewriter font. You can use this command to refer to member function parameters in the running text.
I agree . These seems to be Doxygen commands to format typewritten fonts but since its in comments its not showing the 'font format' but the character itself.
Comments are not touched or processed by Doxygen. They have their own formatting. The /c /p precedes some important keywords (methods, members, parameters etc) only and not arbitrary. The author in all good intentions wanted people to identify the keywords but in comments, all are equal.
I try to find method(function) declerations on which 6th argument is true. Actually I think I can return ,just using regex, wished group without using an extra programming language's feature, unfortunately no option exits as such.
sdfsdfs(123,234,werer,23324,234324,true,dwfwefwer,sdfdsdff);
sdfsdfs(123,234,true,23324,234324,true,dwfwefwer);
sdfsdfs(123,234,234234,23324,234324,r23423,dwfwefwer);
sdfsdfs(123,234,234234,23324,234324,false,dwfwefwer);
(123,234,werer,23324,234324,true,dwfwefwer,sdfdsdff)
erterterterter(123,234,werer,23324,234324,true,dwfwefwer,sdfdsdff);
What I have tried is here. (\b\w+(?=\s*[,()]))
You can check the following regex.
(?i)\w*\([^,]+,[^,]+,[^,]+,[^,]+,[^,]+,true\b,[^\)]+\)
I have done here https://regex101.com/r/BEJNp4/1/
I've been linting my python code for some time now in order to make it more Pythonian and to that effect I've been using pylint to help identify problematic code blocks. However, now I'm having a kind of weird error, where pylint is flagging a correctly formatted constant name as not conforming to the regex provided.
Orginially, the constant was named main, which should match with the regex [a-z\_][a-z0-9\_]{2,30}$, but I got the convention violation message anyway. I tried changing the constant to run_main without any change. I even tried chaning the regex to [\_][a-z0-9\_]{2,30}$|[a-z][\_][a-z0-9\_]{2,30}$but the convention violation persists. I've tried testing the expressions on several regex testing sites to make sure I was not in the wrong. Is it a bug in pylint or am I missing something obvious?
The constant is defined in the following code block:
if __name__ == "__main__":
javabridge.start_vm(class_path=bf.JARS)
run_main = mainInterface()
and the relevant part of my pylintrc file is:
# Naming style matching correct constant names
#const-naming-style=
# Regular expression matching correct constant names. Overrides const-naming-
# style
const-rgx='[\_][a-z0-9\_]{2,30}$|[a-z][\_][a-z0-9\_]{2,30}$'
which yields the following output:
393,4,convention,C0103:Constant name "run_main" doesn't conform to "'[\\_]
[a-z0-9\\_]{2,30}$|[a-z][\\_][a-z0-9\\_]{2,30}$'" pattern ("'[\\_][a-z0-
9\\_]{2,30}$|[a-z][\\_][a-z0-9\\_]{2,30}$'" pattern)
Pylint wants any variable assigned in the outermost scope to be in all uppercase. Calling it MAIN should remove the warning.
I'm trying to set up automated Doxygen runs on our massive 78,000 file C++ codebase. It's doing okay with extracting basic type and hierarchy information, but I'd like to make it smarter about picking up the documentation comments that are already in place.
Most of the comments that have accumulated over the years do follow a general pattern, though not the pattern that Doxygen expected. Mostly they look like
// class description
class foo
{
// returns ascii art of a fruit
const char* apples( void );
// does something to some other thing
customtype_t baz( foo &other );
enum
{
kBADGER, // an omnivorous mustelid
kMUSHROOM, // tasty on pizza
kSNAKE, // oh no!
};
}
Which are double-slashed, rather than the /// or //! style comments that Doxygen expects.
There are far too many files to go through searching and replacing all such comments, and many of my programmers are violently allergic to seeing triple-slashes in their code, so I'd like to find some way to make Doxygen read ordinary comments as JavaDoc comments, when they're in the right place. Is there a way to make Doxygen read // as ///?
I couldn't find any such configuration parameter, so I figure I'll need to transform the input somehow. In general the rule I'd use is:
if there is a line containing just a
comment, immediately preceding a
function/class/type/variable
declaration, assume it is a ///
comment.
if there is a declaration
followed on the same line by a //
comment, treat it as a ///<
But I don't know how to go about teaching Doxygen this rule. The two ways I can think of are:
Write a program as an INPUT_FILTER, which parses the input C++ and transforms //s into ///s as above. But this kind of transform is too complicated to do as a regular expression, and I really don't want to have to write a full blown C++ parser just to feed input to another C++ parser! Also, spinning up an INPUT_FILTER program for each file slows down Doxygen unacceptably: it already takes over 30 minutes to run across our source, and adding an INPUT_FILTER makes it take over six hours.
Modify the Doxygen source code to include the above comment rules. That seems like a scary amount of work in unfamiliar code.
Any other ideas?
The answer is simple: You can't.
The special style of doxygen must be used, to mark a comment as documentation.
Doxygen does NOT only take comments, that precede the declaration. You also could use them everywhere in the code.
If you want to use the doxygen features, you would have to update the comments by hand, or write a script/tool that looks for declarations and preceding comments to change them.
You have to decide, choose one from the 3 solutions (your two, and the script, added as answer) or not using doxygen.
You can use a script to change comment to Doxygen style, here is a simple python script, just try it:
#!/usr/bin/env python
import os
import sys
import re
def main(input_file, output_file):
fin = open(input_file, 'r')
fout = open(output_file, 'w')
pattern1 = '^\s*//\s.*'
pattern2 = '^\s*\w.*\s//\s.*'
for line in fin.readlines():
if re.match(pattern1, line) != None:
line = line.replace('//', '///', 1)
if re.match(pattern2, line) != None:
line = line.replace('//', '///<', 1)
fout.write(line)
fin.close()
fout.close()
if __name__ == '__main__':
if len(sys.argv) != 3:
print 'usage: %s input output' % sys.argv[0]
sys.exit(1)
main(sys.argv[1], sys.argv[2])
I'm trying to understang how to use icu::BreakIterator to find specific words.
For example I have following sentence:
To be or not to be? That is the question...
Word instance of break iterator would put breaks there:
|To| |be| |or| |not| |to| |be|?| |That| |is| |the| |question|.|.|.|
Now, not every pair of break points is actual word.
In derived class icu::RuleBasedBreakIterator there is a "getRuleStatus()" that returns some kind of information about break, and it gives "Word status at following points (marked "/")"
|To/ |be/ |or/ |not/ |to/ |be/?| |That/ |is/ |the/ |question/.|.|.|
But... It all depends on specific rules, and there is absolutely no documentation to understand it (unless I just try), but what would happend with different locales and languages where dictionaries are used? what happens with backware iteration?
Is there any way to get "Begin of Word" or "End of Word" information like in Qt QTextBoundaryFinder: http://qt.nokia.com/doc/4.5/qtextboundaryfinder.html#BoundaryReason-enum?
How should I solve such problem in ICU correctly?
Have you tried the ICU documentation? It appears to explain everything you are asking about including handling of internationalisation, reverse iteration, and the rules, both default and how to create your own custom set. They also have code snippets to help.