I work with a software framework which has a couple of classes with method names containing capital letters (due to C++ wrappers). This is of course not PEP8 and pylint shows the corresponding error C0103. I also added C0111 to the list to ignore the missing docstrings for some methods, like this:
def Configure(self): # pylint: disable=C0103,C0111
It works, however now I get warnings because of the local disablings:
Class: I0011 -> locally disabling C0103
Class: I0011 -> locally disabling C0111
How should I suppress them?
OK, so obviously one has to ignore the ignore-warning explicitly. One can do this in the pylint config file: if you don't have one, simply generate a standard configuration via
pylint --generate-rcfile > pylint.rc
and uncomment the line with disable=... and add I0011 to the list. This suppresses all warnings regarding "locally defined disablings".
The other method is to add the following line to the beginning of a file (or block, whatever), if you don't want to suppress the warning globally:
#pylint: disable=I0011
Related
I've been happily using https://github.com/rubyide/vscode-ruby in VSCode which has been auto-formatting my code on save, until this was merged https://github.com/rubocop-hq/rubocop-rspec/pull/1109 (which is great in itself).
Now when I save a Rspec file with a focused spec, it removes it! eg
On saving fit "something" do, it updates it to it 'something'! (It does not remove disabled specs xit)
vscode-ruby config:
"ruby.intellisense": "rubyLocate",
"ruby.useLanguageServer": true,
"ruby.codeCompletion": "rcodetools",
"ruby.format": "rubocop", // this line causes the formatter to kick in
"ruby.lint": {
"rubocop": true
},
Options
I can bypass this by adding # rubocop:disable RSpec/Focus to the end, but that is annoying
I can disable the cop in my local .rubocop.yml file, but then
either have a local diff, and lose the check against all files when running rubocop on the command line
have to check it in and everyone loses the check
AFAICT there is no command-line option to disable a cop. The inverse of only would be good!
But even if that option was present, can vscode-ruby be configured to modify the command line options?
Others?
This issue seems to have solved itself!
So I guess some dependency was updated that "fixes" it, for now...
I will see if I can find what it is.
Is there a command or some tools that can help you get the corresponding CONFIG_XXX options to enable a module. For example, if I want to enable module nvme, which CONFIG_XXX should be y or m?
I know there are some documents which may states the config of nvme. But I want to know if there is a command or tool which can help you get the CONFIG——XXX only if you type a command.
Thanks.
if I want to enable module nvme, which CONFIG_XXX should be y or m?
As far as I know, there is no documentation or single-purpose command that would report the specific configuration symbol that builds a module.
However the Makefile that actually specifies the building of the module in question is the sole authoritative source for this information.
Typically the relevant Makefile would be in the subdirectory (or the parent directory) as the source module.
If you're not sure where the source module resides, then you could search all the Makefile files in the kernel source for the conditional build of the .o object file:
$ find . -name Makefile | xargs grep nvme.o
./drivers/nvme/host/Makefile:obj-$(CONFIG_BLK_DEV_NVME) += nvme.o
... <irrelevant search results>
$
So the answer would be CONFIG_BLK_DEV_NVME.
Note that the subdirectory that has the relevant Makefile will also have the Kconfig file that describes the configuration symbol you just identified.
Rather than manually edit the .config file, use the make menuconfig command.
Using the menuconfig assures you that your configuration will meet all dependencies and trigger all auto-selections properly.
You can use the search feature (simply type the slash character, /, and the config name) to retrieve help text to guide you to the location of the configuration prompt.
The help text and status of CONFIG_BLK_DEV_NVME could look like:
Symbol: BLK_DEV_NVME [=n]
Type : tristate
Prompt: NVM Express block device
Location:
-> Device Drivers
(1) -> NVME Support
Defined at drivers/nvme/host/Kconfig:4
Depends on: PCI [=n] && BLOCK [=y]
Selects: NVME_CORE [=n]
Selected by [n]:
- NVM [=n] && BLOCK [=y] && PCI [=n]
The current configuration state/status of each configuration entry mentioned is displayed within square brackets and an equals sign.
The Depends on: line indicates that both CONFIG_PCI and CONFIG_BLOCK have to be enabled in order for the CONFIG_BLK_DEV_NVME prompt to be even visible.
You may have to use the search capability to convert these other CONFIG_xxx names to their menu prompts and locations.
The Selects: line indicates the other configuration entries that will be automatically enabled if this config item is selected.
The Selected by [x]: line(s) indicates the other configuration entries that could automatically enable this config item. In this case the logical expression indicates that when three other config entries are enabled, this config is also enabled automatically.
You can search the options in the interactive kernel configuration menu but you have to build the menu first via make menuconfig, then type / followed by the term you're looking for. Each Symbol: in the search results is followed by the option name without CONFIG_ prefix. It also shows location of the option in the menu tree.
Some of the options are tristate: y - the feature is going to be built into the kernel image, m - the feature should reside in a loadable module, n - the feature is disabled.
You need to add CONFIG_BLK_DEV_NVME=m (either edit .config or use make menuconfig) to enable support of nvmeNnM block devices as a loadable module.
I'm getting different results from autodoc when I run sphinx locally (versions 1.6.6 or 2.0.1 on Anaconda Python 3.6.8 for Mac) than when I run it on readthedocs.org (according to their log it's Sphinx version 1.8.5, and probably Python 2.7 since it's launched with python rather than python3).
The difference is in the results from the following file, Shady.Text.rst, which contains no more than:
Shady.Text Sub-module
=====================
.. automodule:: Shady.Text
Now, this sub-module happens to contain only a module-level docstring and no member docstrings—that's as intended, so the corresponding html page should contain the module docstring and no more. And this is exactly what happens when I run make html locally. However the result at https://shady.readthedocs.io/en/latest/source/Shady.Text.html is content-free (header only, no module docstring).
FWIW my autodoc-related entries in conf.py are:
autoclass_content = 'both'
autodoc_member_order = 'groupwise'
What am I doing wrong?
Thanks #StevePiercy for drawing my attention to the crucial lines in the raw log file:
WARNING: autodoc: failed to import module u'Text' from module u'Shady'; the module executes module level statement and it might call sys.exit().
WARNING: autodoc: failed to import module u'Video' from module u'Shady'; the module executes module level statement and it might call sys.exit().
(I had searched the 9000-line log file for .Text, because Text on its creates too many hits, but it hadn't occurred to me to search it for 'Text' in quotes).
To me, the message is misleading: the problem is not that "the module executes module level statements" because that per se is allowed. I wasted some time after noting that some module-level statements seemed to be allowed in other sub-modules, and tried to bundle the offending module-level statements into a class decorator thinking maybe sphinx's mysterious module-level-statement-detector would miss them then...)
No, the problem is that not the fact that the module-level statements exist and might call sys.exit(), but the fact that they did indirectly call sys.exit() during sphinx's compilation procedure. This was a quirk of the way I handle missing dependencies, which should probably be re-thought, but I could work around it for now by avoiding my sys.exit() call when os.environ.get('READTHEDOCS') is truthy.
I use VS2015+ wxwideget 3.10 to run a very simple example from wxwidget examples
Yesterday this example was able to run properly but today the example starts to display "Error C1189 #error: "wxUSE_ACTIVEX must be defined." when building it. I didn't change the configuration settings so this thing is quite confusing. Where could be the bugs?
the place where error occured(in chkconf.h):
f/* ensure that MSW-specific settings are defined */
#ifndef wxUSE_ACTIVEX
# ifdef wxABORT_ON_CONFIG_ERROR
# error "wxUSE_ACTIVEX must be defined."
# else
# define wxUSE_ACTIVEX 0
# endif
#endif /* !defined(wxUSE_ACTIVEX) */
my property settings:
additional include directories: $(WXWIN)\include; $(WXWIN)\include\msvc;
additional library directories: $(WXWIN)\lib\vc_x64_lib
First of all, it's completely impossible that something that worked yesterday stopped working today without anything else. You did change something and, of course, only you know what it was.
Second, all wxUSE_XXX constants are defined in include/wx/msw/setup.h which is copied to lib/vc_x64_lib/mswu/wx (or another similar directory depending on debug/release, lib/DLL build settings) during the library build and is found there by by include/msvc/wx/setup.h. So if it's not defined, the first thing to do is to check that this file didn't get changed somehow (maybe accidentally, although I have trouble imagining how this could happen).
I searched the net and handbook, but I only managed to learn what is the masked package, and not how to install it. I did find some commands, but they don't seem to work on 2008 (looking at it, it seems those are for earlier versions). I have something like this:
localhost ~ # emerge flamerobin
Calculating dependencies
!!! All ebuilds that could satisfy "dev-db/flamerobin" have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-db/flamerobin-0.8.6 (masked by: ~x86 keyword)
- dev-db/flamerobin-0.8.3 (masked by: ~x86 keyword)
I would like to install version 0.8.6, but don't know how? I found some instructions, but they tell me to edit or write to some files under /etc/portage. However, I don't have /etc/portage on my system:
localhost ~ # ls /etc/portage
ls: cannot access /etc/portage: No such file or directory
There are two different kinds of masks in gentoo. Keyword masks and package masks. A keyword mask means that the package is either not supported (or untested) by your architecture, or still in testing. A package mask means that the package is masked for another reason (and for most users it is not smart to unmask). The solutions are:
Add a line to /etc/portage/package.keywords (Check man portage in the package.keywords section). This is for the keyword problems.
Add a line to /etc/portage/package.unmask for "package.mask" problems (you can also use package.mask for the converse). This is in the same man file, under the section package.unmask. I advise to use versioned atoms here to avoid shooting in your own foot with really broken future versions a couple of months down the line.
These days there's also a more 'automated' solution, called "autounmask". No more file editing needed to unmask!
The great benefit of the package is, it also unmasks / handles keywords of dependencies if needed. It's provided in the package app-portage/autounmask.
/etc/portage/package.keywords and
/etc/portage/package.unmask
can be directories as well nowadays (but autounmask handles single files as well). In those directories, multiple can place multiple "autounmask" files, one file in each dir per "unmask"-package. If you use single files instead of dirs, 'autounmask' will place some kind of header / footer, and this way it becomes easy to remove "unmasks" if wanted.
Simply mkdir /etc/portage and edit as mentioned here: http://gentoo-wiki.com/TIP_Dealing_with_masked_packages#But_you_want_to_install_the_package_anyway...