Is there a single argument alternative to the double verbose options for pytest runs? It's a little deceptive looking seeming like a merge error or a benign redundant typo when it shows up in shell script source.
I'm not sure the evolution of the verbosity inputs, but its showing up in our repo from tips like the following that pytest gives upon failures.
...Full output truncated (19 lines hidden), use '-vv' to show
Would be nice if there was something like --verbose2 or something of the sort.
Turns out there is such an option, it's under verbosity.
--verbosity=VERBOSE
and tracing around the codebase seems to imply that 0,1,2 are valid values. There doesn't appear to be any documentation on that point however.
Looking at the command argument definition I can also see the behavior and pattern they're utilizing, which is the count action which sheds new light on redundant arguments; I didn't even realize that was a pattern.
group._addoption(
"-v",
"--verbose",
action="count",
default=0,
dest="verbose",
help="increase verbosity.",
)
So it would seem that
"-vv" === "--verbose --verbose" === "--verbosity=2"
I'm trying to figure out how to modify an XML file with NSIS. So I'm trying to learn how to use the XML plugin. The examples on the forum page often use the format ${plugin::command} like:
${xml::LoadFile}
The documentation gives no indication that you need the dollar sign and curly braces. As I understand it, just plugin::command will do. So I've been trying to figure out what that syntax means.
The documentation says a $ is for variables and the {} are for code blocks, but I can't find anything about what it means when they're used together. My Internet searches have revealed that it's used for something called template literals in JavaScript. But what does it mean in NSIS?
EDIT: I should mention that the NSIS documentation does show examples of this syntax, especially in the Predefines section, but it still doesn't explain what the syntax means in general.
EDIT: Okay, now I see that the syntax is for the compiler to replace things using !define and !macro. But... what about this specific case? Is it valid to use colons in such a symbol? Why are some people writing ${xml::LoadFile}and some people just writing xml::LoadFile?
It's a !define. There is a header file for this plugin that defines it. The plugin probably needs to do more than one thing, so they wrapped a few lines together with a define that inserts a macro. Either that or it has some default parameters for the plugin call. Either way, it's trying to save you some typing with this syntax.
After pouring over the NUnit 3 documentation on Test Selection Language and trying a few combinations, I still cannot figure out how to run all the tests within a specific namespace.
The most obvious attempt being:
nunit3-console.exe --where "test == 'MyNamespace.Subnamespace'" Tests.dll
Unfortunately, this reports zero matching tests, although using the --explore options I can see many tests within that namespace.
Do I need to use regular expression/wildcards to accomplish this? The NUnit docs hint otherwise, but given this doesn't work maybe I do.
It seems the following works:
nunit3-console.exe --where "test =~ 'MyNamespace.Subnamespace'" Tests.dll
Note the squiggle =~ is a regex operator.
This is a bit of a surprise because the only example mentioning namespaces in the documentation uses the == syntax which, given my original experimentation, would not have any effect.
I'm trying to have my Vim setup automatically fold import statements when I open a Scala file. This is similar to what Intellij does when you open a file. I currently have the following lines in my .vimrc file from the wiki.
set foldmethod=syntax
set foldenable
syn region foldImports start=/(^\s*^import\) .\+/ end=/^\s*$/ transparent fold keepend
However when I open a .scala file it doesn't fold the imports but the body of objects. I am also using the vim-scala plugin. Thanks for the help!
You were pretty close to getting this to work. There are a few funky factors at play that we should consider.
setting foldmethod to syntax (btw this is not documented on learn Vimscript the Hardway..so :help foldmethod was key to figure this out)
SYNTAX fold-syntax
A fold is defined by syntax items that have the "fold" argument.
|:syn-fold|
The fold level is defined by nesting folds. The nesting of folds is
limited with 'foldnestmax'.
Be careful to specify proper syntax syncing. If this is not done
right, folds may differ from the displayed highlighting. This is
especially relevant when using patterns that match more than one line.
In case of doubt, try using brute-force syncing:
:syn sync fromstart
The main thing to note is the sync fromstart this is a useful helper if you have regex that would match throughout the file and only want to catch the header. In your case you should be able to ignore this but just something to be aware of.
top down regex scanning
Since the import block is fairly predictable we can simplify the start and end to look something like this:
syn region foldImports start="import" end=/import.*\n^$/ fold keepend
Since the region is just looking for some string to start the matching on we can just use "import"(or /import/) and then for the end value we want to use a little bit more carefully crafted statement. The key is that we want have the end be the last line of the import with a blank line following it (/import.*\n^$/)
Hopefully that does the trick for you (I do not work with scala so you may have to adjust the regex a bit as needed)
It is "common knowledge" that source filters are bad and should not be used in production code.
When answering a a similar, but more specific question I couldn't find any good references that explain clearly why filters are bad and when they can be safely used. I think now is time to create one.
Why are source filters bad?
When is it OK to use a source filter?
Why source filters are bad:
Nothing but perl can parse Perl. (Source filters are fragile.)
When a source filter breaks pretty much anything can happen. (They can introduce subtle and very hard to find bugs.)
Source filters can break tools that work with source code. (PPI, refactoring, static analysis, etc.)
Source filters are mutually exclusive. (You can't use more than one at a time -- unless you're psychotic).
When they're okay:
You're experimenting.
You're writing throw-away code.
Your name is Damian and you must be allowed to program in latin.
You're programming in Perl 6.
Only perl can parse Perl (see this example):
#result = (dothis $foo, $bar);
# Which of the following is it equivalent to?
#result = (dothis($foo), $bar);
#result = dothis($foo, $bar);
This kind of ambiguity makes it very hard to write source filters that always succeed and do the right thing. When things go wrong, debugging is awkward.
After crashing and burning a few times, I have developed the superstitious approach of never trying to write another source filter.
I do occasionally use Smart::Comments for debugging, though. When I do, I load the module on the command line:
$ perl -MSmart::Comments test.pl
so as to avoid any chance that it might remain enabled in production code.
See also: Perl Cannot Be Parsed: A Formal Proof
I don't like source filters because you can't tell what code is going to do just by reading it. Additionally, things that look like they aren't executable, such as comments, might magically be executable with the filter. You (or more likely your coworkers) could delete what you think isn't important and break things.
Having said that, if you are implementing your own little language that you want to turn into Perl, source filters might be the right tool. However, just don't call it Perl. :)
It's worth mentioning that Devel::Declare keywords (and starting with Perl 5.11.2, pluggable keywords) aren't source filters, and don't run afoul of the "only perl can parse Perl" problem. This is because they're run by the perl parser itself, they take what they need from the input, and then they return control to the very same parser.
For example, when you declare a method in MooseX::Declare like this:
method frob ($bubble, $bobble does coerce) {
... # complicated code
}
The word "method" invokes the method keyword parser, which uses its own grammar to get the method name and parse the method signature (which isn't Perl, but it doesn't need to be -- it just needs to be well-defined). Then it leaves perl to parse the method body as the body of a sub. Anything anywhere in your code that isn't between the word "method" and the end of a method signature doesn't get seen by the method parser at all, so it can't break your code, no matter how tricky you get.
The problem I see is the same problem you encounter with any C/C++ macro more complex than defining a constant: It degrades your ability to understand what the code is doing by looking at it, because you're not looking at the code that actually executes.
In theory, a source filter is no more dangerous than any other module, since you could easily write a module that redefines builtins or other constructs in "unexpected" ways. In practice however, it is quite hard to write a source filter in a way where you can prove that its not going to make a mistake. I tried my hand at writing a source filter that implements the perl6 feed operators in perl5 (Perl6::Feeds on cpan). You can take a look at the regular expressions to see the acrobatics required to simply figure out the boundaries of expression scope. While the filter works, and provides a test bed to experiment with feeds, I wouldn't consider using it in a production environment without many many more hours of testing.
Filter::Simple certainly comes in handy by dealing with 'the gory details of parsing quoted constructs', so I would be wary of any source filter that doesn't start there.
In all, it really depends on the filter you are using, and how broad a scope it tries to match against. If it is something simple like a c macro, then its "probably" ok, but if its something complicated then its a judgement call. I personally can't wait to play around with perl6's macro system. Finally lisp wont have anything on perl :-)
There is a nice example here that shows in what trouble you can get with source filters.
http://shadow.cat/blog/matt-s-trout/show-us-the-whole-code/
They used a module called Switch, which is based on source filters. And because of that, they were unable to find the source of an error message for days.