Warning on prepending variables with $ - phpstorm

When I have a selector that I use several times, I like to prepend it with $ So if I'm using $('body') all over my script, I'll make a variable, $body. The warning arises, in this particular case, when I do $anElement.appendTo($body) I get the warning:
Argument type JQuery|jQuery|html element is not assignable to parameter type JQuery|element|string
I was told this is actually pretty common and acceptable practice, so is there a way I can turn this warning off? I couldn't seem to find any particular entry that disabled this in the inspections.
What I'm doing is this:
$('<div>,
{class:"aClass", text: "some text"}
).appendTo($body);

The warning is under Javascript > General > Signature Mismatch.

Related

How to find and disable specific NVCC warning?

Where are the NVCC codes for a specific warning listed?
Looking at other questions like this one gives the answer to use -Xcudafe "--diag_suppress=xxx to suppress warning "xxx", and links to a list of possible warnings here.
However, when I have the warnings
/usr/include/eigen3/Eigen/src/Core/util/XprHelper.h(94): warning: __host__ annotation is ignored on a function("no_assignment_operator") that is explicitly defaulted on its first declaration
and
/usr/include/eigen3/Eigen/src/Core/util/XprHelper.h(94): warning: __device__ annotation is ignored on a function("no_assignment_operator") that is explicitly defaulted on its first declaration
I do not find that type in the list. Can someone point me to the page where it is, so I can find the code/name of it? I did not find it in the documentation for NVCC.
Instead of looking for the string code for the warning, you can pass the
--display_error_number flag to NVCC, and get the number of that error. Then you can disable it with:
-Xcudafe --diag_suppress=1234
or whatever the error number was.
This specific warning can be suppressed with the following flag:
-Xcudafe --diag_suppress=esa_on_defaulted_function_ignored

Is there an equivalent to Octave's "lookfor" command in Julia?

How to seek a concrete function in Julia? lookfor would make it in Matlab / GNU Octave, how can it be done here?
The equivalent of lookfor is apropos:
julia> apropos("fourier transform")
Base.DFT.fft
julia> apropos("concatenate")
Base.:*
Base.hcat
Base.cat
Base.flatten
Base.mapslices
Base.vcat
Base.hvcat
Base.SparseArrays.blkdiag
Core.#doc
Other useful functions, depending on what you're looking for, include methodswith, which can give you a list of methods that are specified for a particular argument type:
julia> methodswith(Regex)
25-element Array{Method,1}:
==(a::Regex, b::Regex) at regex.jl:370
apropos(io::IO, needle::Regex) at docs/utils.jl:397
eachmatch(re::Regex, str::AbstractString) at regex.jl:365
eachmatch(re::Regex, str::AbstractString, ovr::Bool) at regex.jl:362
...
A comment on Fengyang's great answer. Notice the difference between searching at the Julia prompt with apropos("first") vs typing a question mark and the word ?first.
As you type the question mark, the prompt changes to a question mark. If you type "first", this is equivalent to the above (with less typing). If you type first without quote-marks, you get a search over the variables that are exported by the modules currently loaded.
Illustration:
help?>"first"
Base.ExponentialBackOff
Base.moduleroot
... # rest of the output removed
help?>first
search: first firstindex popfirst! pushfirst! uppercasefirst lowercasefirst
first(coll)
Get the first element of an iterable collection. Return the start point of
an AbstractRange even if it is empty.
... # rest of the output removed
If you search for a string, case is ignored. If you want to search within the DataFrames module, type using DataFrames before searching.

Understanding the use of Tcl namespace variable

I have a namespace variable which is defined as below:
namespace eval ::SMB::{
variable SmbInfo
------
------
proc ::SMB::SmbCreate {name dutport} {
variable SmbInfo
global DutPorts DutPort_2 DutPorts_3 smb
------
------
if{"" != [info command SMB::$name]} {
return -code error "command name \"$name\" already exists"
}
set SmbInfo($name -DutPort) $dutport
I am new to Tcl and trying to understand the above piece of code. Few questions, please correct me if I am wrong at any point:
The variable SmbInfo defined on top in namespace is getting overridden by the one declared in the procedure SmbCreate. I am unable to figure out what is the objective of the line:
set SmbInfo($name -DutPort) $dutport
I can see that 'DutPorts' is defined as global but I could not find 'DutPort'. I have not executed the code yet. Could it be an error?
Is ($name - DutPort) creating an array index for the variable SmbInfo and the value of $dutport is being set to that particular array variable?
I have similar code structures in the file like below
set SmbInfo($name - SmbSetDmac) [BuildMac1 $SmbInfo($from_name-DutPort)]
Where BuildMac1 is a procedure. A bit explanation of the above code might also make the thing clear.
If anything I missed to post in the question, kindly point me, I will edit my question.
Thanks in advance.
The second declaration doesn't override, it's the same variable in both cases.
The command is a syntax error because of the space after $name. The intent seems to be to assign the value of $dutport to the member of SmbInfo that has the name "$name -DutPort" (where $name is replaced by the variable value).
A similar assignment, but here the value comes from the result of the command.
There are a few syntax errors in the code, too many or too few spaces here and there. It seems unlikely this code has ever been executed.
The purpose of the smb::SmbCreate command would seem to be to 1) create a new command in the SMB namespace named by the first parameter (unless such a command already exists) and 2) store metadata in the SmbInfo namespace variable, indexed by a) the name parameter and b) a keyword such as -DutPort or -SmbSetDmac.
Code like this essentially implements an ad-hoc object-oriented interface. If the whitespace issues are resolved, it should work fine.
You have many syntactic problems that are going to cause you much grief. Tcl cares very much about its syntax level, which includes exactly where the spaces and newlines are, and whether there are {braces} and [brackets] as expected. You must get these things right.
Looking at the specific code you're having problems with, this line:
set SmbInfo($name -DutPort) $dutport
would appear to be highly unlikely, as it is passing three arguments to the set command when that only takes one or two. I'd guess that you've got a command that you're calling to obtain a key for an array, and that the code therefore ought to be this:
set SmbInfo([$name -DutPort]) $dutport
See those [brackets]? They matter here, as they say “run my contents as a little subscript and use the result”. With that sorted out, there's also the question of whether $name -DutPort works at all, but you'll just have to be guided by the error messages there. Tcl usually gives very good error messages, though sometimes you have to think about why the code got in the state where it is giving that message in order to figure out what the actual problem is. You know, usual debugging…
I would expect similar problems with:
set SmbInfo($name - SmbSetDmac) [BuildMac1 $SmbInfo($from_name-DutPort)]
and would guess that it is actually supposed to be:
set SmbInfo([$name -SmbSetDmac]) [BuildMac1 $SmbInfo([$from_name -DutPort])]
Note again that I have modified the spaces to follow the existing pattern (which I'm guessing is a property access; it looks like it's OTcl or XOTcl) and added brackets.
Finally, this line:
if{"" != [info command SMB::$name]} {
is also syntactically wrong, and should instead be:
if {"" != [info command SMB::$name]} {
That extra space matters, because it separates the word that is the command name (if) from the word that is the condition expression. The remainder of the line is probably correct (the SMB::$name might be suspicious, except you're using it in info command, but then you probably only need info command $name as it already knows about what namespace you're working in and you're using the unqualified name elsewhere).

How can I disable the "unused attribute" warning when using Serde library?

In addition to disabling the warning, why does it happen?
use serde_json::from_str;
use serde_json::error::Result;
#[derive(Deserialize)]
pub struct Config {
#[serde(rename="cudaBlasDylibPath")]
pub cuda_blas_dylib_path: String,
}
impl Config {
pub fn new() -> Result<Config> {
from_str("{}")
}
}
src/config.rs:4:10: 4:21 warning: unused attribute, #[warn(unused_attributes)] on by default
src/config.rs:4 #[derive(Deserialize)]
Adding #[allow(unused_attributes)] doesn't help.
Here's the full output from the compiler:
src/main.rs:10:10: 10:21 warning: unused attribute, #[warn(unused_attributes)] on by default
src/main.rs:10 #[derive(Deserialize)]
^~~~~~~~~~~
src/main.rs:10:10: 10:21 note: in this expansion of #[derive_Deserialize] (defined in src/main.rs)
What this means is that the warning is within the code for the impl generated by the #[derive] attribute. However, it's hard to understand what's going on without seeing the code!
Fortunately, we can ask the compiler to show us the generated code. We need to pass additional parameters to rustc, specifically -Z unstable-options --pretty=expanded. If you're using Cargo, delete the compiled crate or run cargo clean (Cargo does nothing if the target is up to date), then run this command:
$ cargo rustc -- -Z unstable-options --pretty=expanded > src/main-expanded.rs
We can then try to compile src/main-expanded.rs with rustc. If you're using Cargo, use the command Cargo prints when you run cargo build --verbose (when the target is not up to date), but replace the name of the root source file with the new file we just generated – or you can just swap your main.rs or lib.rs with the expanded source. It might not always work, but when it does, it can provide some valuable insight.
We now get a clearer picture of the situation:
src/main-expanded.rs:17:5: 17:43 warning: unused attribute, #[warn(unused_attributes)] on by default
src/main-expanded.rs:17 #[serde(rename = "cudaBlasDylibPath")]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/main-expanded.rs:20:1: 20:25 warning: unused attribute, #[warn(unused_attributes)] on by default
src/main-expanded.rs:20 #[automatically_derived]
^~~~~~~~~~~~~~~~~~~~~~~~
Here, the warning on the #[serde] attribute is probably caused by the fact that the struct no longer has the #[derive(Deserialize)] attribute, which is what processes the attribute. Also, it's not part of the expansion of the #[derive(Deserialize)] attribute, so that's not the attribute the original warning complained about.
It looks like the #[automatically_derived] attribute is the culprit here. This attribute appears to be used mainly by rustdoc (the documentation generation tool), but it has no meaning when compiling.
The implementation of #[derive] for derivable traits known to rustc emits the attribute like this:
let attr = cx.attribute(
self.span,
cx.meta_word(self.span,
InternedString::new("automatically_derived")));
// Just mark it now since we know that it'll end up used downstream
attr::mark_used(&attr);
My guess is that serde doesn't call the mark_used function, which is what causes the warning. The only occurrences of "automatically_derived" in serde's source code are in invocations of the quote_item! macro, which probably doesn't emit a call to mark_used (and it should probably not do it either).

How to (accidentally) write into the global context (namespace) with coffeescript?

I accidentally stumbled over the following code that actually modified the global namespace:
I though this is not possible?
The following code writes three variables into the global namespace (try it):
this.my_global1=1
#my_global2=2
f= -> #my_global3=3
f()
If you now replace the above code with this in the cofeescript try page
alert("#{[my_global1,my_global2,my_global3]}")
you will see an alert with
1,2,3
This means the statements above modify the global context!
It took me many hours to figure out what was going wrong with my code, because I thought coffeescript protects me form accidental changes of the global environment!
CoffeeScript can't prevent you from doing this, but JavaScript can. Use strict mode:
do ->
"use strict"
this.$ = 3
In non-strict mode, this defaults to window if it isn't specified when the function is called. In strict mode, this becomes undefined, which will throw an error if you try to assign properties to it:
TypeError: Cannot set property '$' of undefined