So for example, why i need scan.rules when there is something like sfportscan preprocessor ? Is it because preprocessor can not detect all the activities and so there is detecting engine using rules with well known signatures of network attacks trying to find match ? But there are also preproc rules, so i am bit confused now. So preprocessor use their own rules and then there are normal rules in case none of this preproc rules found the match ?
Thank you for answer.
Preprocessor rules are used to enable or disable (or change) events triggered by preprocessors. See snort manual.
The file scan.rules has nothing to do with the sfportscan preprocessor. It is meant as a container file to hold rules that detect possible scanning events. This eases the exclusion/inclusion of rules for users that don't need the whole ruleset.
Related
When linting dart files, one of the checks that seems relatively standard (and part of the google pedantic style) is unnecessary_this, which favors not using the explicit this keyword unless necessary when the instance variable is shadowed.
Coming from more of a Java/Python background, where (in Java) the standard seems to favor explicit use of this., plus a pretty typical checkstyle check RequireThis, I'm wondering the rationale behind dart's preference for this type of style check - to me it seems Java and Dart have similar semantics for implicit this's, so why are the standard preferences opposing each other?
In the unnecessary_this docs, it says:
From the style guide:
DON'T use this when not needed to avoid shadowing
However the linked style guide does not mention it or provide any rationale.
I'm wondering because I'd like to have a check that is the exact opposite of unnecessary_this, but there doesn't seem to be one so I'm curious if there's something about dart I don't know that is rationale for implicit this.
Dart's style-guide focuses a lot on "don't write what is not necessary", and unnecessary_this is one of its representations
The overall rationale behind it is that by removing the obvious redundant bit, this decrease visual noise, and therefore increase readability (while also being easier to type).
The only reason I can think of for wanting a "require this" lint is to avoid getting confused by variable shadowing. But then, might as well have a lint for "don't shadow variables".
I want to define custom directive using some built-in ones and my logic.
As I see all of Directive.apply, BasicDirectives.mapInnerRoute and Directive.tflatMap is suitable.
What is preferable in which cases and what best practices are?
Without knowing anything about the custom directives you wish to create it's impossible to discuss the suitability of the various options you listed.
The documentation on this topic is fairly thorough:
There are essentially three ways of creating custom directives:
By introducing new “labels” for configurations of existing directives
By transforming existing directives
By writing a directive “from scratch”
I currently have the following grammar below:
COMPONENT = HEADER BODY
BODY = ELEMENT+
ELEMENT = EXPRESSION | DECLARATION | DESCRIPTION | NAME
I would like to assert that the body must have one of each of the ELEMENT in any order. Currently I am checking this after parsing, I am however curious if it's possible to express this in the grammar using Parser Combinators particularly guards
I tried doing further research regarding this, but nothing seems to come up.
Yes, it is possible. You simply write down all the valid permutations. This gets out of hand, fast.
It isn't worth the trouble to express in the grammar, because in essence you are trying to establish a constraint across the syntax, and grammars are really best at expressing context-free constraints.
Better to parse with grammar rules simply allowing all of the possibles clauses as options, and build your semantic pass (you will have one anyway) to check the additional constraints.
When writing a grammar, you should move as many constraints as possible to the semantic pass instead of the syntactic pass. This greatly improves the ability of the parser to recover from errors during parsing, and allows you to fully control the manner and wording used when reporting the error to users. For the case of permutations, the increased flexibility in the parser will likely reduce the size of the parsing tables as well.
I would like to know if there is anyone who has implemented the subjectscheme maps of DITA1.2 in their work? If yes, can you please break-up the example to show:
how to do it?
when not to use it?
I am aware of the theory behind it, but I am yet to implement the same and I wanted to know if there are things I must keep in mind during the planning and implementation phase.
An example is here:
How to use DITA subjectSchemes?
The DITA 1.2 spec also has a good example (3.1.5.1.1).
What you can currently do with subject scheme maps is:
define a taxonomy
bind the taxonomy to a profiling or flagging attribute, so that it the attribute only takes a value that you have defined
filter or flag elements that have a defined value with a DITAVAL file.
Advantage 1: Since you have a taxonomy, filtering a parent value also filters its children, which is convenient.
Advantage 2: You can fully define and thus control the list of values, which prevents tag bloat.
Advantage 3: You can reuse the subject scheme map in many topic maps, in the usual modular DITA way, so you can apply the same taxonomies anywhere.
These appear to be the main uses for a subject scheme map at present.
The only disadvantages I have found is that I can think of other hypothetical uses for subject scheme maps such as faceted browsing, but I don't think any implementation exists. The DITA-OT doesn't have anything like that yet anyway.
I've been implementing my own scripting language + virtual machine from scratch for a small experiment. A script reader parses the script and translates it to a stream of instructions that a runtime engine will execute.
At the beginning I didn't think about it but now I'd like to include flow control (loops, branching etc). I'm not well versed with language theory and just looked at some examples for inspiration.
But both the x86 and the java virtual machine have a plethora of instructions used for flow control. In x86 there are plenty instructions that jump based on the state of flags and other instructions that manipulate the relevant flags one way or another. In Java there seem to be 16 instructions that make some sort of comparison and a conditional jump.
This might be efficient or motivated by hardware specific reasons but it's not what I'm looking for.
I look for a lean, elegant solution to flow control that only requires a few dedicated instructions and isn't too complicated to implement and maintain.
I'm pretty confident I could come up with something that works but I'd rather improve my knowledge instead of reinventing the wheel. Any explanations or links to relevant material are very welcome!
Generally the minimum primitives required for flow control are
unconditional jump
conditional jump
Of these, the conditional jump is the complex one, and at a minimum it needs to support the following atomically:
test a binary variable/flag
if the flag is set, cause instruction execution to jump to some specified location
if the flag is unset, allow instruction execution to continue uninterrupted
However with such a primitive conditional jump, you would need ways to set that binary variable/flag to the appropriate value for every type of boolean expression that could be used in the flow control structures of your language.
This would therefore either lead to the need for various primitives of varying complexity for setting the binary variable/flag, or the need to emit complex sequences of instructions to get the desired effect.
The other alternative is to introduce more complex conditional jump primitives.
Generally there will be a trade-off between the number and complexity of each of: conditional jump primitives; condition (variable/flag) setting primitives; emitted instructions.