There are many JSLint options with which to configure the extent by which JSLint may ignore code quality issues.
The web interface, for boolean options, allows you to toggle between choices of true, false and default. This implies that if a given option has no explicit value chosen a default, or implicit, value will be used.
Many options allow for certain "bad" uses of JavaScript to be tolerated, implying that the default is 'false'. as one intent of JSLint is to discourage "bad" uses.
If merely true or false were possible choices, with false being the default, a regular checkbox, or any other input offering binary and not ternary choices, might be expected to be used. Given that the web interface allows for one's choice to revert to default suggests that false might not always be the default choice for a given option.
It is not clear to me from examining the latest source what values the selection of options will take if not explicitly chosen.
For all the JSLint options, what default values are used?
Am I correct in assuming that boolean options default to 'false' if not specified and that integer options (indent, maxerr and maxlen) default to those values present in the source?
In JSLint, all of the boolean options are false by default. That effectively means that JSLint is as strict as it can be. All of the options, when set, will lessen the restrictions it places on your code.
I think the reason the web interface uses those "true"/"false"/"default" toggles is that there is a different behaviour for the global directive. The default state for any global identifier is simply "not present" - click one of them to add a set of global identifiers as true, click again to set them to false, and click again to remove that set of identifiers.
If global identifiers are listed with true, then JSLint will not complain if it encounters an assignment. If false, an assignment to a global identifier will generate a warning. Again, false is the default:
/*global $ */ // Define $ globally, don't allow assignments
/*global $:false */ // Equivalent to the above
/*global $:true */ // Allow assignment
Related
In build definition (on Variables tab) I am trying to define a custom variable (Build.Repository.Clean) using simple expression $[not(false)]. But when I print variables during build -- regardless of expression used, Build.Repository.Clean value is always false.
Strangely enough, definining it with something like $(FullBuild) (where FullBuild is another custom variable) works just fine.
Am I missing something?
Notes:
using TFS 2018
Backstory:
Trying to set Build.Repository.Clean variable depending on a custom variable QuickBuild (which can be set by user when kicking off a build). Tried specifying $[not(variables.QuickBuild)] (and other variations of same expression) -- no luck.
here is how it works right now (but I'd rather have QuickBuild instead of FullBuild -- just can't figure out how to negate a variable):
Update 3:
Well, ignore if it changes clean operation during queue time. For what you are looking for, you could try this format:
Build.Repository.Clean=$[not(eq(variables.QuickBuild,'True'))]
If QuickBuild=True, Build.Repository.Clean=False,
If QuickBuild=False, then Build.Repository.Clean.Clean=True
For example:
I have set the clean option in Get Source Step, Clean=true
Build.Repository.Clean=$(FullBuild)
FullBuild=false
Now when I queue the build, then try to change the FullBuild=false during queue
time.
What you thought, the Build.Repository.Clean should change to False , then the clean operation will not be executed. But the truth is, the Build.Repository.Clean is still True and the clean is executed.
Even you do not update the value of FullBuild=false during the queue time, directly set the value FullBuild=false in build pipeline. This will also not use.
In the opposite, if you set Clean=false in Get Source Step. No matter what kind of value you input in FullBuild or Build.Repostiory.Clean during queue build.
It will not clean during the build pipeline.
Conclusion: It's not able to change the clean operation during queue time. This is not related any expression at all. Not matter what kind of value you set for Build.Repository.Clean.
Update 2
After go through your question and all comments once again. Seems your truly goal is assigning the clean options at queue-time based another customized variable.
Since you are not able to change Build.Repository.Clean during queue time. So you are trying to use this workaround. It's not support. There is not a way to assign the clean options at queue-time.
You may have to pre-define this variable in your build pipeline.
Also take a look at this question: How to clean build using self-hosted agent when queuing
In your scenario, you can create two build pipelines as an ugly workaround. One for incremental build (Disable the Clean option in get source step, or use variable Build.Repository.Clean = False), and another one enable the Clean option.
Hope it's clearly.
Expressions are not evaluated when they are used to initialize custom variables (on Variables tab). I.e. variable value ends up being a string with value equal to your expression (e.g. '$[not(<whatever>)]'). Later, when that variable gets used in context that expect boolean -- it still doesn't get evaluated, instead it gets type-casted and any non-empty string yields true.
On the other hand variable substitution happens -- i.e. value $(MyVar) gets replaced with value of MyVar.
Built-in variable seem to be special in sense that if you override them -- this process happens at the start and it's value gets immediately replaced with resulting value.
Note -- this may (or may not) be related to this.
Bottomline: you can't use expressions to override value of a built-in variable.
I was wondering if it is possible to set default options for Vue.draggable? Currently I find I need to keep supply the options for each draggable when some (like the handle and scroll sensitivity) would be better set globally.
%draggable{ 'v-model': 'values', '#change': 'move', ':options': '{handle: ".handle", scrollSensitivity: 80}', 'element': 'tbody' }
Excuse the HAML.
It is not possible, You can use a store to keep the default parameters and reuse them in diferent components.
Note that starting with version 2.19 the syntax is:
v-bind="{handle: '.handle', scrollSensitivity: 80}"
Or
handle=".handle" :scrollSensitivity="80"
I am sure this is documented somewhere but unable to find the answer anywhere.
if I have:
```bazel_rule(
name = "foo",
srcs = ["foo.cpp"],
attr_bar = "bar"
)```
if I have a reference to this rule (//src:foo) in a Starlark (.bzl) file, how can I query the target to get a value of a specific attribute. e.g. get_attribute("//src:foo", "attr_bar") should return "bar" in this example.
It depends on whether you're trying to read the attribute from a macro, a rule, or an aspect.
Short answers:
A macro can't read attributes of a target (roughly, macros are evaluated at build file loading time, and attributes are evaluated later at analysis time). You can do things like taking in the attributes you care about and creating the rule (bazel_rule in your example) within the macro, so that the macro has the attribute value, but this usually quickly becomes messy and hard to follow.
A Starlark rule also can't directly read attribute values from dependencies (it can read its own attributes though, of course). The rule you're interested in (bazel_rule here) has to put the information in a provider and the Starlark rule reads the provider from its dependencies.
An aspect can read the attributes of the rule its being evaluated on directly through ctx.rule.attr.<attr_name>(the example here does this).
I use Kapacitor auto load directory for delivering tick scripts to all envs https://docs.influxdata.com/kapacitor/v1.4/guides/load_directory/
one requirement: you need set "dbrp"
other way you get error:
failed to create task: must specify dbrp
In the same time I want to debug/modify (see log) of this alert in Chronograf web interface (http://****:8888/sources/1/tickscript/)
but can not do it cause Error message:
cannot specify dbrp in implicitly and explicitly
as Chronograf provide one more "select database" control.
May be someone now is it possible to debug pre-load tick script in Chronograf ui?
In https://docs.influxdata.com/kapacitor/v1.5/tick/syntax/#declarations
the following paragraph is instructive:
A database declaration begins with the keyword dbrp and is followed by two strings separated by a period. The first string declares the default database, with which the script will be used. The second string declares its retention policy. Note that the database and retention policy can also be declared using the flag -dbrp when defining the task with the command kapacitor define on the command-line, so this statement is optional. ...
Since it is optional in the TICKscript, then you can just set database declaration can be set from the command line when you load the script, e.g.
kapacitor define load_1 -tick ~/tick/telegraf-autogen/load_1.tick -dbrp "telegraf"."autogen"
Defined this way, the dbrp is considered implicitly set since it's not defined in the TICKscript. If you define it in the TICKscript, then it is explicitly set. This small detail unlocks this conundrum - define dbrp on the load script and not the TICKscript.
Coded this way, if you later save the TICKscript in the cronograf TICKscript editor, you won't get this error, since it's not explicitly set in the TICKscript.
Yes, you have to track two pieces of code, e.g. the TICKscript and the command line you use to load it into kapacitor. Suggestion, add a hint in the TICKscript will help reduce confusion regarding the intended dbrp. Also, group TICKscripts in subdirs by dbrp (as shown above) along with the load script in that dir, would keep things clean.
When I enter a breakpoint in Xcode I can see the Variables View in the Debugger area.
Since the UInt32 type that I am working with represents Unicode values, I would like to change the display value from decimal to hexadecimal or some Unicode type. I can do that by right-clicking and selecting View Value As.
Which gives
But I find myself having to do this over and over.
Is there any way to change the default display type?
I thought I had seen this before, but it turns out that it was a similar question for Android Studio. I looked in preferences but couldn't see anything there either.
The "type format add" command will do what you want. Do:
(lldb) help type format add
for more details. It will change the default format for any variable of the given type. You can either enter these at the lldb prompt or in your ~/.lldbinit. One caveat, the Xcode locals view doesn't update itself when the formatters change, so you will have to "step" to get the format change to register.
Another trick you can use if you have a mix of UInt32's that you use for this purpose and others that you use as UInt32's (and thus would want to see with the default format), you can create a typealias to UInt32, and use that when you intend the Unicode usage. Then you can put the formatter on the typealias rather than on UInt32. That way you will get the formatting where you want it and not in other uses.
Another little trick that you can use is to add your special type formats to a category when you make them (using the -w option.) That allows you to use the "type category enable/disable" to turn your special formatting on and off without having to remember the "type format add" command. If you do this, note that categories are created "disabled", so you will have to enable the category before you will see its effects.