I was wondering if there is a TSLint rule with which I can disallow the following code:
var arr = [1, 2];
//the line below should be disallowed
arr.prop1 = "3";
//because arr now has array elements and object properties
I want to disallow this because it prevents arr from being fully serialized with JSON.stringify, because JSON.stringify will serialize arr into [1, 2].
I have looked at the TSLint rules but wasn't able to find a rule for this.
I've implemented a TSLint rule for this, which is available on GitHub and NPM:
https://github.com/leroydev/no-setting-array-properties-rule
https://www.npmjs.com/package/no-setting-array-properties-rule
It can be used like this:
Install it using npm install no-setting-array-properties-rule --save-dev.
Add it to your tslint.json, like this:
{
"rulesDirectory": [
"../node_modules/no-setting-array-properties-rule/dist/src"
],
"rules": {
"no-setting-array-properties": true
}
}
Edit:
It can be implemented by just setting noImplicitAny: true too, for my project this wasn't an acceptable solution, but that's the easy fix.
Related
When you post an query with syntax errors graphql/graphene makes suggestions to you. By example, sending "i", it suggest "ID".
query{
users{
i
}
}
{
"errors": [
{
"message": "Cannot query field \"i\" on type \"User\". Did you mean \"id\"?",
"locations": [
{
"line": 5,
"column": 9
}
]
}
]
}
Can suggestions be disabled?
More info:
Syntax analysis who add suggestions is executed before the middlewares.
Apparently suggestions are made by ScalarLeafsRule class.
Ok, people in graphql-core github repo is awesome, they helped to me to solve this.
So graphql-core has two relevant versions, 3 (current) and 2.3.2 (legacy).
For graphql-core 3, quoting to Cito
Ok, if you want to keep it closed and also disable introspection it makes a little more sense. I suggest you simply set graphql.pyutils.did_you_mean.MAX_LENGTH = 0. I just commited a small change ffdf1b3 that makes this work a bit better.
You can also ask over at https://github.com/graphql/graphql-js/issues if they want to add some functionality to support your use case. From there it would be ported back here.
For legacy version:
from graphql.validation import rules
def get_empty_suggested_field_names(schema, graphql_type, field_name):
return []
def get_empty_suggested_type_names(schema, output_type, field_name):
return []
rules.fields_on_correct_type.get_suggested_field_names = get_empty_suggested_field_names
rules.fields_on_correct_type.get_suggested_type_names = get_empty_suggested_type_n
You can place it on django settings file.
Please follow all the thread on https://github.com/graphql-python/graphql-core/issues/97
I want to initialize an array in this way:
int arr
{
3,
4
};
But my emacs misindents it to:
int arr
{
3,
4
};
Please note a missing "=". I am using an initializer list here and this syntax is correct.
Using a more recent version of emacs might help. The indentation of braced initializer list was improved in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24431.
Emacs 26.1 indents the same code as
int arr
{
3,
4
};
which is not all the way there but at least better.
As an alternative I would like to suggest clang-format with Emacs
There are plenty of options you can play with.
These options are to be defined in a .clang-format file (in your home directory or in your C++ project root directories)
And what about nesting initializer lists, with trailing commas, which are now supported (c++11)?
Say I was building JSON. (cpprestsdk)
what I see:
using JsonValue = web::json::value;
auto json = JsonValue::object({
{"a", JsonValue("v")},
{"b", JsonValue::array({
{JsonValue(1)},
{JsonValue::object({
{},
{},
})},
{JsonValue(3)},
})},
{"c", JsonValue::object()},
});
what I want to see
auto json = JsonValue::object({
{"a", JsonValue("v")},
{"b", JsonValue::array({
{JsonValue(1)},
{JsonValue::object({
{},
{},
})},
{JsonValue(3)},
})},
{"c", JsonValue::object()},
});
Assuming I prefer starting with Allman/BSD basic formatting...
I am trying to customize my Awesome Window Manager to change the tag numbers into Roman numbers (changing 1 for I, 2 for II...). In order to achieve this, I am modifying my /etc/xdg/awesome/rc.lua file, specially the {{tags}} section.
I have found this blog post, in which he manages to edit the tag names at will, have a look at the top left corner:
I also read the rc.lua file attached to the theme, and realized the technique used for what I want to do is a for loop in combination with some tables.
This is the code snippet of interest in the file:
-- {{{ Tags
-- Define a tag table which hold all screen tags.
tags = {}
tagnames = { "irc", "mpd", "net", "usr", "png", "msg", }
taglayouts = {
awful.layout.suit.tile.top,
awful.layout.suit.tile.bottom,
awful.layout.suit.floating,
awful.layout.suit.fair,
awful.layout.suit.floating,
awful.layout.suit.floating }
for s = 1, screen.count() do
-- Each screen has its own tag table.
tags[s] = {}
for tagnumber = 1, 6 do
-- Add tags and name them.
tags[s][tagnumber] = tag(tagnames[tagnumber])
-- Add tags to screen one by one, giving them their layouts at the same time.
tags[s][tagnumber].screen = s
awful.layout.set(taglayouts[tagnumber], tags[s][tagnumber])
end
-- I'm sure you want to see at least one tag.
tags[s][1].selected = true
end
-- }}}
...and this is my rc.lua file:
-- {{{ Tags
-- Define a tag table which hold all screen tags.
tags = {}
tagnames = { "I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX", }
taglayouts = {
awful.layout.suit.tile.top,
awful.layout.suit.tile.bottom,
awful.layout.suit.floating,
awful.layout.suit.fair,
awful.layout.suit.floating,
awful.layout.suit.floating }
for s = 1, screen.count() do
-- Each screen has its own tag table.
-- tags[s] = awful.tag({ "1", "2", "3", "4", "5", "6", "7", "8",$
tags[s] = {}
for tagnumber = 1, 9 do
tags[s][tagnumber] = tag(tagnames[tagnumber])
tags[s][tagnumber].screen = s
awful.layout.set(taglayouts[tagnumber], tags[s][tagnumber])
end
tags[s][1].selected = true
end
--- }}}
As you can see, they are pretty the same, with the difference that I have nine tags instead of six (I changed the code according to it). When I try to debug the setup using Xephyr, an error appears in the console and I am only able to see my wallpaper:
error while running function
stack traceback:
[C]: in global 'tag'
/etc/xdg/awesome/rc.lua:100: in main chunk
error: /etc/xdg/awesome/rc.lua:100: bad argument #2 to 'tag' (table expected, got string)
error while running function
stack traceback:
[C]: in global 'tag'
/etc/xdg/awesome/rc.lua:100: in main chunk
error: /etc/xdg/awesome/rc.lua:100: bad argument #2 to 'tag' (table expected, got string)
E: awesome: main:605: couldn't find any rc file
I can't see where the error is, as I am not able to detect any language violation in the error line tags[s][tagnumber] = tag(tagnames[tagnumber]): it's just filling the tags array with my custom names, telling it to treat them as a tag and not as a random string.
UPDATE: I have just realized that there are six layouts in taglayouts, the same number as tags in the original Lua file. I think I should have nine tag layouts, but I don't know which one should I add. Also, I don't see this as a critical impediment for the code to compile properly, as the error line does not have anything to do with the layout list.
UPDATE 2: Added three more awful.layout.suit.floating to taglayouts. Same error.
Following another answer, I replaced my {Tags} section with:
-- {{{ Tags
-- Define a tag table which hold all screen tags.
tagnum = { "I", "II", "III", "IV", "V", "VI", "VII",
"VIII", "IX" }
for i = 1, 9 do
awful.tag.add((tagnum[i]), {
layout = awful.layout.suit.tile,
master_fill_policy = "master_width_factor",
gap_single_client = true,
gap = 15,
screen = s,
})
end
-- }}}
This creates i number of tags, their name defined in the tagnum table. This is only useful if you want to create identical tags, but it will always be much cleaner than having to type i definitions.
A MUCH BETTER, CLEANER WAY:
The initial solution was useful, but it had a problem: when starting AwesomeWM, you won't appear in a defined tag, but in all of them at the same time. That is, if you open a terminal, you will open it in every tag you have unless you previously selected one with Mod4+TagNum (following default conf.).
Trying to solve this problem, I compared the default configuration file with the modded one, and I realized it all worked well in the default one. So I started modifying the code in order to find a solution. In all, I have discovered that with a minimal modification of the default code you are able to customize your tag names at will. This is how I did it:
-- {{{ Tags
tags = {}
-- Generates tags with custom names
for s = 1, screen.count() do
tags[s] = awful.tag({ "I", "II", "III", "IV", "V", "VI", "VII", "IX" }),
end
-- }}}
P.S. I keep the old solution in case someone would wish to use the code for another purpose.
Not an official answer yet, but yesterday I wrote more doc about this:
https://github.com/awesomeWM/awesome/pull/1279/files#diff-df495cc7fcbd48cd2698645bca070ff9R39
It is for Awesome 4.0, but in this case not much changed, so the example is almost valid (the gap property is not available in 3.4/3.5).
Also, if you wish to setup complex tags, I would suggest my Tyrannical module (Awesome 3.5+) or Shifty (Awesome 3.2-3.4). It is designed to make this much easier.
I'm using YAML for a computer and human-editable and readable input format for a simulator. For human readability, some parts of the input are mostly amenable to block style, while flow style suits others better.
The default for PyYAML is to use block style wherever there are nested maps or sequences, and flow style everywhere else. *default_flow_style* allows one to choose all-flow-style or all-block-style.
But I'd like to output files more of the form
bonds:
- { strength: 2.0 }
- ...
tiles:
- { color: red, edges: [1, 0, 0, 1], stoic: 0.1}
- ...
args:
block: 2
Gse: 9.4
As can be seen, this doesn't follow a consistent pattern for styles throughout, and instead changes depending upon the part of the file. Essentially, I'd like to be able to specify that all values in some block style sequences be in flow style. Is there some way to get that sort of fine-level control over dumping? Being able to dump the top-level mapping in a particular order while not requiring that order (eg, omap) would be nice as well for readability.
It turns out this can be done by defining subclasses with representers for each item I want not to follow default_flow_style, and then converting everything necessary to those before dumping. In this case, that means I get something like:
class blockseq( dict ): pass
def blockseq_rep(dumper, data):
return dumper.represent_mapping( u'tag:yaml.org,2002:map', data, flow_style=False )
class flowmap( dict ): pass
def flowmap_rep(dumper, data):
return dumper.represent_mapping( u'tag:yaml.org,2002:map', data, flow_style=True )
yaml.add_representer(blockseq, blockseq_rep)
yaml.add_representer(flowmap, flowmap_rep)
def dump( st ):
st['tiles'] = [ flowmap(x) for x in st['tiles'] ]
st['bonds'] = [ flowmap(x) for x in st['bonds'] ]
if 'xgrowargs' in st.keys(): st['xgrowargs'] = blockseq(st['xgrowargs'])
return yaml.dump(st)
Annoyingly, the easier-to-use dumper.represent_list and dumper.represent_dict don't allow flow_style to be specified, so I have to specify the tag, but the system does work.
Found a couple of questions (and answers) on this: How is internationalization configured for Hogan.js?
,etc.
but non in particular that take word order into account. I need the ability to:
step 1. given a key -> lookup a sentence in a particular language.
step 2. this sentence may contain {{var}} , which need to be
substituted by json-values.
step 2. alone is general mustache-templating.
step 1. alone could be done with several techniques, but I prefer techniques that don't involve any specialized code outside of the Mustache/Hogan engine (in combination with a i18n-resource bundle of course) . Hogan seems to support this with something like: (from url above)
var template = "{{#i18n}}Name{{/i18n}}: {{username}}",
context = {
username: "Jean Luc",
i18n: function (i18nKey) {return translatedStrings[i18nKey];}
};
However to combine 1. and 2. in this example I would want translatedStrings[i18nKey] to return a string which potentially contains {{<some expansion>}} as well.
Someone knows of an elegant way to do this?
Rationale:
Often languages differ a lot in word order, etc. which makes for complex templates without this ability.
The latest version of Hogan.js will handle Mustache tags inside the result returned from a lambda. One minor change to the code in your question however, is that the result of the lambda should be a function in order to modify the string:
var translatedStrings = { name: "Nom {{rank}}" };
var template = "{{#i18n}}name{{/i18n}}: {{username}}",
context = {
username: "Jean Luc",
rank: 'Captain',
i18n: function() {
return function (i18nKey) {return translatedStrings[i18nKey];};
}
};
document.write(Hogan.compile(template).render(context)); // Nom Captain: Jean Luc
I created a jsfiddle that demonstrates this with the latest version.