I'm using VSCode with the python extension. The 'problems' tab as well as the indicators on the 'explorer' tab and the red underline in the code view itself all show there to be an error, even though the error isn't real.
After importing matplotlib.pyplot as plt, the code uses plt.cm.RdBu. VSCode is presenting the error that matplotlib.cm has no member RdBu.
There are two issues here:
Unless I'm just mistaken, plt.cm.RdBu ought to be equivalent to matplotlib.pyplot.cm.RdBu, not matplotlib.cm.RdBu. It seems to be interpreting that incorrectly.
But regardless of that, both cm and pyplot.cm actually do have an attribute called RdBu, both of which I was able to pull up information for using help(). The code runs perfectly and python throws no errors.
Why is VSCode telling me this is an error when it isn't? Is this just a bug or could it be a misconfiguration?
Unfortunately, there doesn't seem to be a way to fix this issue. The reason that VS Code, or more specifically, the linter used by the Python extension isn't picking up matplotlib.pyplot.cm.RdBu, or any other colormaps defined in cm is because they're defined dynamically. If you try looking inside cm.py, you'll only find this:
cmap_d = _gen_cmap_d()
locals().update(cmap_d)
Essentially, instead of being statically defined like RdBu = ..., these colormaps are defined dynamically by being injected into the module's global namespace at runtime. Even though this works fine when you run it, unfortunately it means that there's no way for the linter to know that names such as RdBu exist in the namespace until runtime. And as most linters such as pylint and flake8 are static code analysis tools that never actually execute the code, it's impossible for them to detect the existence of these colormaps.
Related
I am working with Python in VS Code. I have two modules, mod_A and mod_b, where mod_A imports a method do_this_thing from mod_B. Everything was going fine until I tried to refactor do_this_thing into _do_this_thing. (The function is an internal function).
I used the Rename Symbol option in VS Code to perform the refactor. I doublechecked that all instances in my fairly simple code base were covered.
The strange behavior that I'm getting is that when I run mod_A and it gets to the renamed function call, I get an AttributeError telling me that there is no function _do_this_thing. The head scratcher, though, is that if I manually change _do_this_thing back into do_this_thing in mod_A, my code executes as expected— even though it is still defined as _do_this_thing in mod_B! Furthermore, I can't step into do_this_thing when I run it in mod_A.
I have tried deleting all __pycache__ files, as that was the first thing that I thought of. I've also tried clearing VS Code's cache, deleting my project, and starting over with the refactor from a fresh pull from GitHub. No dice.
Hopeful that someone here can help me solve this esoteric problem!
Edit: Adding some debugging context for the votes to close my question:
Windows 10, VS Code
Miniconda Python distribution
PYTHONPATH variable has project directory on it
Modules imported correctly; the bug happened when I changed the name of a function in the module being imported
Python appears to be importing a cached verison of the earlier code from somewhere, but I've reset everything and still have the issue
My program has a very specific error that took me a while to track down - now I don't know how to fix it. My code is very long and in many files and I don't see much point in posting it here.
In the IDE, everything runs fine, in both Debug and Release (with the runtime library set to either /MTd or /MT, respectively, so I'm assuming all dependencies are included).
However, when I run the standalone, I get a crash. At first I thought it was a dependency problem but it doesn't seem so.
At some point in the code, I am accessing a vector via a method call: t->GetList(), where GetList is defined as std::vector<T*> & GetList() and the method simply returns a member variable (simply defined as std::vector<T*> field in the class).
It turns out, if I print out the size of the list while running from the IDE, I get 0 (which is the correct answer in this case).
However, when doing the same thing running from standalone, I get the size as 467467353.
I tried changing the method declaration to std::vector<T*> * GetList() and doing return &field; and updating the rest of the code but this didn't fix anything.
I then tried replacing the member variable field with a pointer, and in the constructor instantiating a new vector and deleting it in the destructor. Still no luck.
So I made a simple test case program that simply made a class with a vector field, and a method to return a reference to it. Then in main I would create an instance variable and getting the vector and printing the size. This worked both in VC++ and as a standalone - both returned zero.
This is driving me nuts and I can't figure out why I'm getting different behaviour. Why is the standalone running differently, and what should I be looking at to fix this?
Thanks
Okay so it was literally a bug in my code that was very well hidden. I was dynamically casting to a wrong type.
Somehow it slipped past when I was running on Windows and OSX in both Debug and Release, and as a standalone on OSX. Good thing I found it.
I am currently working on a Node.JS project written in TypeScript using Node.JS Tools for Visual Studio (NTVS). I have a few classes and enums spread out in 3 or 4 files in my project. I am now trying to use the classes defined in those files from my main app file. From my previous work with Node, I know that I would normally need a require call to import each other file/class if I were working with a text editor and the command-line compiler. But, if I open any TypeScript file in my project and start typing the name of a class defined in a different file, Visual Studio shows IntelliSense autocomplete for the class name and its members. This makes me think that the NTVS and/or TypeScript configuration are automatically making all of my classes available project-wide. But if I click the 'run' button, errors are printed to the console because Node can't find the referenced classes at runtime.
This behavior leads me to believe that IntelliSense isn't actually telling me that the classes are available, just that they exist (which seems odd). If I add a require call to the top of the file, and use that imported value instead of the original class name, Node finds the class and I can use it in my code. But this presents two problems:
I must come up with a new name to use for the variable that I import the class into. If I require() it with the original name, Visual Studio shows errors saying that the identifier is a duplicate, because it seems to believe that the original class is available project-wide.
I don't get the autocomplete or type checking in my usage of the class. This pretty much defeats the purpose of using TypeScript.
So, what's the proper way to do this import? Is there a way to make all my classes available globally? If not, what import statements do I need?
This behavior leads me to believe that IntelliSense isn't actually telling me that the classes are available, just that they exist
unless you have top level import or export statement the file is considered a global module and is available project wide : http://basarat.gitbooks.io/typescript/content/docs/project/modules.html
A global module will not work at runtime in node.js
You should use file level modules using import/export and compile with --module commonjs
In an IPython notebook, one would expect the following code to cause Raphael.js to load successfully into the global namespace.
from IPython.display import Javascript
raphael_url = "https://cdnjs.cloudflare.com/ajax/libs/raphael/2.1.0/raphael-min.js"
Javascript('alert(Raphael);', lib=[raphael_url])
However, it does not work in recent versions of IPython which use require.js. Turns out, Raphael.js, which IPython loads using jQuery.getScript(), recognizes the presence of require.js and as such does not insert itself into the global namespace. In fact, if one first runs javascript code removing the window.define object, Raphael no longer realizes require.js is present, and it inserts itself into the global namespace as I would like. In other words, the code above works after running the following:
Javascript('window.define = undefined;')
Thus, the only way I am able to get Raphael to load within a recent version of IPython notebook is to delete (or set aside) window.define.
Having identified the problem, I am not familiar enough with require.js to know what piece of software is acting against protocol. Is Raphael using a poor way of testing for the existence of require.js? Should IPython be using require.js directly instead of jQuery.getScript() when it loads user-provided javascript libraries? Or is there a way I as the user ought to be embracing require.js, which will give me the Raphael object without needing any special hacks? (If the answer to the last question is yes, is there a way I can also support older versions of IPython notebook, which do not use require.js?)
The first part of my answer won't please you, but the loading and requirement of javascript library in the IPython-notebook-webapp has not yet been solved, so for now I would suggest not to build to much on the assumption you can load library like that, and rely more on custom.js for now.
That being said, if raphael is not in global namespace require is smart enough to cache it, and give you reference to it. Then in the callback you can just assign to a global :
require(['raphael'], function( raph ){
window.raphael = raph;
})
Or something like that should do the trick.
I have an erlang program, compiled with rebar, after the new debian release, it won't compile anymore, complaining about this:
-import(erl_scan).
-import(erl_parse).
-import(io_lib).
saying:
bad import declaration
I don't know erlang, I am just trying to compile this thing.
Apparently something bad happened to -import recently http://erlang.org/pipermail/erlang-questions/2013-March/072932.html
Is there an easy way to fix this?
Well, -import(). is working but it does NOT do what you are expecting it to do. It does NOT "import" the module into your module, nor does it go out, find the module and get all the exported functions and allow you to use them without the module name. You use -import like this:
-import(lists, [map/2,foldl/3,foldr/3]).
Then you can call the explicitly imported functions without module name and the compiler syntactically transforms the call by adding the module name. So the compiler will transform:
map(MyFun, List) ===> lists:map(MyFun, List)
Note that this is ALL it does. There are no checks for whether the module exists or if the function is exported, it is a pure naive syntactic transformation. All it gives you is slightly shorter code. For this reason it is seldom used most people advise not to use it.
Note also that the unit of code for all operations is the module so the compiler does not do any inter-module checking or optimisation at all. Everything between modules like checking a modules existence or which functions it exports is done at run-time when you call a function in the other module.
No, there is no easy way to fix this. The source code has to be updated, and every reference to imported functions prefixed with the module in question. For example, every call to format should be replaced with io_lib:format, though you'd have to know which function was imported from which module.
You could start by removing the -import directives. The compilation should then fail, complaining about undefined functions. That is where you need to provide the correct module name. Look at the documentation pages for io_lib, erl_scan and erl_parse to see which functions are in which module.
Your problem is that you were using the experimental -import(Mod) directive which is part of parameterized modules. These are gone in R16B and onwards.
I often advise against using import. It hurts quick searches and unique naming of foreign calls. Get an editor which can quickly expand names.
Start by looking at what is stored in the location $ERL_LIBS, typically this points to /usr/lib/erlang/lib.