My narration has code snippets, e.g., ::SomePlatformAPI() that are not part of my code base and Doxygen warns that
warning: explicit link request to 'SomePlatformAPI()' could not be resolved
I tried to add \code and \endcode around it but then the code block starts a new paragraph and breaks the current narration.
Is there a way to add inline code blocks?
UPDATE:
This turns out to be only a problem of Doxygen 1.8 and above.
With 1.6, you don't have this issue.
Doxygen markdown support allows you to insert inline code blocks using the ` backtick character.
http://www.doxygen.nl/manual/markdown.html#md_codespan
When you do this the code will be injected inline, but it will be monospaced, and doxygen processing will be disabled between the two ` marks. So you will not have to escape tokens.
A a matter of fact, to make it stand out even more I included an extra style sheet with the following in it:
code
{
background-color:#EFD25E;
}
That will hylight the inline code. Doxygen's code spans use a custom tag
<code></code>
Found the solution myself:
All I need to do is to escape the :: token and other similar tokens ->.
For example
\:\:
\-\>
Related
I saw this syntax I'm not familiar with in the Kotlin compiler test suite.
// !DIAGNOSTICS: +UNUSED_LAMBDA_EXPRESSION, +UNUSED_VARIABLE
fun unusedLiteral(){
<!UNUSED_LAMBDA_EXPRESSION!>{ ->
val <!UNUSED_VARIABLE!>i<!> = 1
}<!>
}
What does <!UNUSED_LAMBDA_EXPRESSION!>...<!> mean?
Found in unusedLiteral.kt
The term UNUSED_LAMBDA_EXPRESSION is declared in Errors.kt to be:
DiagnosticFactory0<KtLambdaExpression> UNUSED_LAMBDA_EXPRESSION = DiagnosticFactory0.create(WARNING);
This syntax is not valid Kotlin. It is only used in the test data files of Kotlin's test pipeline. That is, only the test runners recognises this syntax, not the Kotlin compiler. Specifically, the <!DIAGNOSTIC_NAME!>foo<!> syntax denotes a handler. Handlers do checks on things, or output information to a file. In this case, this syntax checks that there is indeed the specified diagnostic being emitted at that point in the file.
Also note that the // !DIAGNOSTICS comment at the top is not just a comment. It denotes a directive. Directives are like the options for running the test.
I highly recommend you read compiler/testData/diagnostics/ReadMe.md, which explains how diagnostic tests work specifically, and if you're really interested in this stuff, check out compiler/test-infrastructure/ReadMe.md too, which tells you all about how the whole test pipeline works in general.
This is how I wrote it, but I get
Parse Error: Unrecognised Input
How can I circumvent this?
I do not want to declare individual mixin for focus, active and disabled states.
I am using WinLess for compiling on Windows 7.
WinLess version:1.9.1
Less.js version:2.1.2
Here is my code
.state(#state,#property,#colour){
&:#{state}{
#{property}:#colour;
}
}
Any help is appreciated.
The best solution to is to update your Less.js compiler to the latest version (v 2.5.3) because it compiles the code provided in the question as-is without the need for any modifications.
However, if you can't upgrade the compiler for whatever reasons then you would need an intermediate variable to form the pseudo-class selectors and then use them like in the below snippet:
.state(#state,#property,#colour){
#sel: ~":#{state}";
&#{sel}{
#{property}:#colour;
}
}
#demo{
.state(hover,color,red);
}
When I generate my parser with bison, I obtain this warning:
warning: stray `#'
But that is because I have some legal Objective-C code containing #, for instance this is one of the rules having the warning:
file : axiom production_rule_list { NSLog(#"file"); }
;
Is there any risk to use # in the code? If not, how to tell bison that it is a legitimate use of #?
Thanks in advance.
The message is just a warning. You can ignore it. If you're using Xcode, it won't even show you the warning in its Issue Navigator.
Rename your Bison input file to have a .ym extension instead of a .y extension. That tells Xcode that it's a grammar with Objective-C actions.
If you want to suppress the warning, you can use a #define AT #.
The code in the braces is just copied, apart from replacing the $… sequences with the code to give the relevant token. This appears to work fine with Objective-C, although if you're using ARC, you might need to do some digging (or just add extra blocks (in the C sense)) to make sure that objects are freed as soon as possible.
As per the documentation in Actions - Bison 2.7, it appears that the code between the curly braces is expected to be C code. As such I doubt that you can use objective-c constructs there.
However you could create an external C function to do the work for you like:
Logit(char* message)
{
NSLog(#"%s",message);
}
And use that in the Bison action
file : axiom production_rule_list { Logit("file"); }
;
Encountered a strange error when I tried to compile following code:
package main
import fmt "fmt"
func main()
{
var arr [3]int
for i:=0; i<3; i++
{
fmt.Printf("%d",arr[i])
}
}
Error is as follows:
unexpected semicolon or newline before {
After correction following code worked:
package main
import fmt "fmt"
func main(){
var arr [3]int
for i:=0; i<3; i++{
fmt.Printf("%d",arr[i])
}
}
Is GO language this much strictly Typed? And this doesn't have warnings also. Should this not be a programmers choice how he wants to format his code?
Go language warnings and errors
The Go language does automatic semicolon insertion, and thus the only allowed place for { is at the end of the preceding line. Always write Go code using the same style as gofmt produces and you will have no problems.
See Go's FAQ: Why are there braces but no semicolons? And why can't I put the opening brace on the next line?
go language includes semicolons with a specific rule, in your case, the newline after the i++ introduces a semicolon before the '{'. see http://golang.org/doc/go_spec.html.
formatting is somewhat part of the language, use gofmt to make code look similar, however, you can format your code many different ways.
Should this not be a programmers choice how he wants to format his
code?
Maybe. I think it is nice that Go steps forward to avoid some bike-shedding, like never ending style discussions. There is even a tool, gofmt, that formats code in a standard style, ensuring that most Go code follows the same guidelines. It is like they were saying: "Consistency everywhere > personal preferences. Get used to it, This Is Good(tm)."
Go code has a required bracing style.
In the same way that a programmer can't choose to use braces in python and is required to use indentation.
The required bracing style allows the semicolon insertion to work without requiring the parser to look ahead to the next line(which is useful if you want to implement a REPL for GO code)
package main
func main();
is valid Go code and without looking at the next line the parser assumes this is what you meant and is then confused by the block that isn't connected to anything that you've put after it.
Having the same bracing style through all Go code makes it a lot easier to read and also avoids discussion about bracing style.
Go lang fallows strict rules to maintain the unique visibility for the reader like Python, use visual code IDE, it will do automatic formatting and error detection.
Aside from getting any real work done, I have an itch. My itch is to write a view engine that closely mimics a template system from another language (Template Toolkit/Perl). This is one of those if I had time/do it to learn something new kind of projects.
I've spent time looking at CoCo/R and ANTLR, and honestly, it makes my brain hurt, but some of CoCo/R is sinking in. Unfortunately, most of the examples are about creating a compiler that reads source code, but none seem to cover how to create a processor for templates.
Yes, those are the same thing, but I can't wrap my head around how to define the language for templates where most of the source is the html, rather than actual code being parsed and run.
Are there any good beginner resources out there for this kind of thing? I've taken a ganer at Spark, which didn't appear to have the grammar in the repo.
Maybe that is overkill, and one could just test-replace template syntax with c# in the file and compile it. http://msdn.microsoft.com/en-us/magazine/cc136756.aspx#S2
If you were in my shoes and weren't a language creating expert, where would you start?
The Spark grammar is implemented with a kind-of-fluent domain specific language.
It's declared in a few layers. The rules which recognize the html syntax are declared in MarkupGrammar.cs - those are based on grammar rules copied directly from the xml spec.
The markup rules refer to a limited subset of csharp syntax rules declared in CodeGrammar.cs - those are a subset because Spark only needs to recognize enough csharp to adjust single-quotes around strings to double-quotes, match curley braces, etc.
The individual rules themselves are of type ParseAction<TValue> delegate which accept a Position and return a ParseResult. The ParseResult is a simple class which contains the TValue data item parsed by the action and a new Position instance which has been advanced past the content which produced the TValue.
That isn't very useful on it's own until you introduce a small number of operators, as described in Parsing expression grammar, which can combine single parse actions to build very detailed and robust expressions about the shape of different syntax constructs.
The technique of using a delegate as a parse action came from a Luke H's blog post Monadic Parser Combinators using C# 3.0. I also wrote a post about Creating a Domain Specific Language for Parsing.
It's also entirely possible, if you like, to reference the Spark.dll assembly and inherit a class from the base CharGrammar to create an entirely new grammar for a particular syntax. It's probably the quickest way to start experimenting with this technique, and an example of that can be found in CharGrammarTester.cs.
Step 1. Use regular expressions (regexp substitution) to split your input template string to a token list, for example, split
hel<b>lo[if foo]bar is [bar].[else]baz[end]world</b>!
to
write('hel<b>lo')
if('foo')
write('bar is')
substitute('bar')
write('.')
else()
write('baz')
end()
write('world</b>!')
Step 2. Convert your token list to a syntax tree:
* Sequence
** Write
*** ('hel<b>lo')
** If
*** ('foo')
*** Sequence
**** Write
***** ('bar is')
**** Substitute
***** ('bar')
**** Write
***** ('.')
*** Write
**** ('baz')
** Write
*** ('world</b>!')
class Instruction {
}
class Write : Instruction {
string text;
}
class Substitute : Instruction {
string varname;
}
class Sequence : Instruction {
Instruction[] items;
}
class If : Instruction {
string condition;
Instruction then;
Instruction else;
}
Step 3. Write a recursive function (called the interpreter), which can walk your tree and execute the instructions there.
Another, alternative approach (instead of steps 1--3) if your language supports eval() (such as Perl, Python, Ruby): use a regexp substitution to convert the template to an eval()-able string in the host language, and run eval() to instantiate the template.
There are sooo many thing to do. But it does work for on simple GET statement plus a test. That's a start.
http://github.com/claco/tt.net/
In the end, I already had too much time in ANTLR to give loudejs' method a go. I wanted to spend a little more time on the whole process rather than the parser/lexer. Maybe in version 2 I can have a go at the Spark way when my brain understands things a little more.
Vici Parser (formerly known as LazyParser.NET) is an open-source tokenizer/template parser/expression parser which can help you get started.
If it's not what you're looking for, then you may get some ideas by looking at the source code.