I have installed a fresh copy of MeshLab by executing the following commands:
git clone --recursive https://github.com/cnr-isti-vclab/meshlab
bash meshlab/install/linux/linux_setup_env_ubuntu.sh
bash meshlab/install/linux/linux_build.sh
I would like to load some meshes of the ModelNet40 dataset, which contains *.OFF files.
Now, when I load a mesh into the image viewer meshlabjs, then the file seems to look correct:
But when I load the same mesh into MeshLab itself, then it is displayed with strong artifacts and it seems like there happened a strong decimation:
Question: Why do these differences in displaying appear? Is it possible, that there are filters automatically applied, from older installations of MeshLab on my mashine? How can I fix this, to display the "correct" looking meshes inside MeshLab instead?
Note: If I export the "broken" mesh and save it somewhere else and display it inside MeshLabJS, then it looks the same broken way with artifacts as it did in MeshLab before.
It is interesting to mention, that the number of vertices and faces is the same in both cases: Correct geometry and incorrectly loaded geometry.
I have checked MeshLab > Filters > Current Filter Script , but the list there is empty. I am on Ubuntu 19.04 and I use MeshLab version 2020.03.
Here is another example. Incorrectly loaded geometry:
Correctly loaded geometry:
When importing pygame pylint is going crazy:
E1101:Module 'pygame' has no 'init' member
E1101:Module 'pygame' has no 'QUIT' member
I have searched the net and I have found this:
"python.linting.pylintArgs": ["--ignored-modules=pygame"]
It solves the problem with pygame, but now pylint is going crazy in other way: crazy_pylint.png.
Then I have found "python.linting.pylintArgs": ["--ignored-files=pygame"], but what it does is completely disabling pylint for the whole directory I am working in.
So how do I say pylint that everything is OK with pygame?
For E1101:
The problem is that most of Pygame is implemented in C directly. Now, this is all well and dandy in terms of performance, however, pylint (the linter used by VSCode) is unable to scan these C files.
Unfortunately, these same files define a bunch of useful things, namely QUIT and other constants, such as MOUSEBUTTONDOWN, K_SPACE, etc, as well as functions like init or quit.
To fix this, first things first, stop ignoring the pygame module by removing all your arguments in "python.linting.pylintArgs". Trust me, the linter can come in handy.
Now to fix the problems. For your constants (anything in caps), manually import them like so:
from pygame.constants import (
MOUSEBUTTONDOWN, QUIT, MOUSEMOTION, KEYDOWN
)
You can now use these without prepending them with pygame.:
for event in pygame.event.get():
if event.type == QUIT:
pygame.quit()
if event.type == KEYDOWN:
# Code
Next, for your init and other functions errors, you can manually help the linter in resolving these, by way of 2 methods:
Either add this somewhere in your code: # pylint: disable=no-member. This will deactivate member validation for the entire file, preventing such errors from being shown.
Or you can encase the line with the error:
# pylint: disable=no-member
pygame.quit()
# pylint: enable=no-member
This is similar to what the first method does, however it limits the effect to only that line.
Finally, for all your other warnings, the solution is to fix them. Pylint is there to show you places in which your code is either pointless, or nonconforming to the Python specs. A quick glance at your screenshot shows for example that your module doesn't have a docstring, that you have declared unused variables...
Pylint is here to aid you in writing concise, clear, and beautiful code. You can ignore these warnings or hide them (with # pylint: disable= and these codes) or spend a little time cleaning up everything.
In the long run, this is the best solution, as it'll make your code more readable and therefore maintainable, and just more pleasing to look at.
For a specific binary module you can whitelist it for pylint. For the pygame module it would be as follows:
{
"python.linting.pylintArgs": [
"--extension-pkg-whitelist=pygame"
]
}
OP You can also maintain the pylint pygame fix you found in vscode by including the vscode default arguments yourself.
The linter is going nuts (crazy_pylint.png) because you were clobbering the default pylint arguments with your own custom python.linting.pylintArgs.
The pygame module ignore fix does work, and the linter can return to non-crazy mode by also including the clobbered default arguments in your own custom python.linting.pylintArgs.
From the docs:
These arguments are passed whenever the python.linting.pylintUseMinimalCheckers is set to true (the default).
If you specify a value in pylintArgs or use a Pylint configuration file (see the next section), then pylintUseMinimalCheckers is implicitly set to false.
The defaults vscode passes according to this: https://code.visualstudio.com/docs/python/linting are:
--disable=all,
--enable=F,E,unreachable,duplicate-key,unnecessary-semicolon,global-variable-not-assigned,unused-variable,binary-op-exception,bad-format-string,anomalous-backslash-in-string,bad-open-mode
So, here is how to pass all those defaults as well as the --ignored-modules=pygame in user settings within vscode:
"python.linting.pylintArgs": [
"--disable=all",
"--enable=F,E,unreachable,duplicate-key,unnecessary-semicolon,global-variable-not-assigned,unused-variable,binary-op-exception,bad-format-string,anomalous-backslash-in-string,bad-open-mode",
"--ignored-modules=pygame"
]
Per #C._ comment above, he's definitely speaking truth; the linter will help!
I'm writing better code with it enabled for sure.
Also, I discovered that you can further fine-tune your pylinter with the enable line and comma delimited "readable pylint messages"
listed here: https://github.com/janjur/readable-pylint-messages/blob/master/README.md
So to not ignore also trailing-newlines, you would append the enable= list argument to include simply trailing-newlines.
I really hope this helps you OP :) It helped me!
Thanks for asking the question, and sharing --ignored-modules.
In vanilla browserify you can specify "paths" option to set directories where browserify looks for "required" files.
browserify({paths: ["./source/App"]})
When using tsify to compile TypeScript, this option seems to be ignored. The reason for using paths in the first place, is to avoid having every require statement start with "../../../etc".
I know an alternative option is to place the code in node_modules, but firstly that does seem pretty odd (you wouldn't normally keep you application code with your dependencies) but it also requires you to commit node_modules to your repositories and make sure no one ever clears that directory to reinstall dependencies.
The other alternative; symlinks don't work on windows, and also seems like quite a "hacky" solution.
I am quite new to browserify (coming from RequireJS), so it is possible that I overlooked something. But at this point I really would appreciate some input. If it makes any difference I am also using gulp.
Well, given that Path mappings based module resolution feature is proposed for TypeScript 1.8 and tsify is a thin wrapper of the TypeScript compiler, I can't imagine a way how it can work nowadays.
I expect that TypeScript 1.8 will be ready in a few months.
From one of the comment in the webstorm blog article, it says one can debug a grunt program by creating a script file and invoke with grunt. I have a gulp setup I like to profile. So, I created a script file with
var gulp = require('gulp');
require('./gulpfile');
gulp.start.apply(gulp, ['default'])
when I run this with a spy-js run session, it executes and ton of trace info. The traced application window shows it ran correctly as I could see the logs. But, I cannot find any of my methods in trace run window. Where should I look for say, a function called from my gulpfile.js? I tried quick search by clicking on middle window and start typing. But I cannot find any of my method.
Another qn, how to go to the next hit in the quick search window. As in the attached image, it hit one result, but I want to go to the next. How?
The best way would be to use capture exclusions to get rid of the noise from the files you're not interested in.
On the screenshot above, single file filter is applied (meaning that nothing but this file will be captured), so after applying such filter and restarting the session you will only see the code from gulpfile.js. You can use glob patterns to include/exclude files you need. I suspect in your scenario excluding all node modules should be enough. There's a shortcut to create such filter, just right click on the root node inside the events pane and select "Mute node modules":
If you're interested in tracing some of the node modules, you can modify the filter to exclude just those you're not interested in. You can also create filters for individual node modules by locating one of their functions in the stack tree and using "Mute this node module" context action.
The make files generated by CMake have a colorful output for improved readability.
Is it possible to change the color? I have a green terminal font so I kind of loose the color for the messages indicating that objects are built.
I assume you are talking about the cmake added messages from the make output (and not the normal make output itself) in which case it looks like those lines are hard-coded into the generated makefiles with arguments to the cmake cmake_echo_color command that include literal color names as arguments. So there don't appear to be any variables to override or anything of the sort that would let you change that.
So, no, it looks like you cannot control the colors that cmake uses for its various messages. At all.
It doesn't even get the values it uses to control the colors from your terminal's termcap/terminfo it has hard-coded escape sequences in the source code from what I can tell.
The only think you can do is change your terminal's color definitions.
Edit:
While discussing this with a colleague we came up with a fairly obvious and unsophisticated workaround for this. Create a cmake wrapper script, assign the path to it to the $(CMAKE) variable (the only variable in use on that generated make line) and then your wrapper needs to scan for the -E cmake_echo_color command sequence and replace whatever color the command was going to be using with the appropriate argument for the color you want to use.
The only problem with this approach is that there is nothing in the command line that indicates any category or any of the sort other than the message itself so to do this in anything resembling a coherent fashion is going to require a filtering on (potentially random) message texts.
As of 2022, it still isn't possible to change the colors.
I've filed two bugs about this with Kitware:
https://gitlab.kitware.com/cmake/cmake/-/issues/23277
https://gitlab.kitware.com/cmake/cmake/-/issues/23279
So maybe things will improve like they have for ccmake.