I already refresh DB!
The example can be work.
My problem is IntelliSense is work on line 5, 6
But at the line 7, tree(parameter) can't not find the method xpath()
IntelliSense is not work on line 7, why?
I try to find the answer, someone say need to Removing project __init__.py can fix the problem.
Where is the __init__.py ?
And there exists other good method to solve problem? like: update VS2013?
This is actually just a limitation of PTVS. To figure out the type of tree, it needs to figure out what etree.parse will return when passed a StringIO and HTMLParser. Depending on the code in parse, this may be near impossible to do without actually executing it.
If you hover over tree, I suspect you'll see that it is an unknown type. To force it to have a certain type, you can write:
assert isinstance(tree, WhateverType)
This will let PTVS know that it will definitely be of that type, though at runtime your program will crash if you are wrong. When support for type hints is added, you will be able to use those instead (but that will likely require updating to the very latest version of Visual Studio).
Related
Is there any way to automatically fix 'invalid-envar-default' pylint issue?
None of the tools that I tried (autopep8, autoflake and black) do not automatically fix this issue.
The solution seems to be pretty straightforward for all cases, ensuring the second parameter is a string (it could be just wrap it with str():
Going from:
os.getenv('SECRET_KEY', 1) # [invalid-envvar-default]
to: os.getenv('SECRET_KEY', '1')
pylint does not have autofix at the moment. ruff aim to do that, but has few lints available at the moment (and not 'invalid-envar-default'). It's likely that this kind of check will be dropped from pylint or not implemented in ruff because it's really really close to what a type checker should do generically applied on a single parameter of a single function. It feel like a remnant of time when type checker where not available. (source: I'm a pylint maintainer and I'm thinking about removing this check outright).
So to sump up, the optimal way to fix this right now is manually.
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.
Aite, [first poster here, pls don't bash]
So, I'm using the sound library, which I of course remembered to import, and works just fine, proof being given by the fact that all the other functions I used work as expected and give no problems neither in editor nor in execution.
Except, of course, for this little bugger of a pause() function, which I wrote as per below using no different a syntax from all the other functions, only to find out Processing isn't very keen on accepting its existence.
Problem shows both using 3.3.6 and 3.5.
Oh, and also, apparently isPlaying() returns an int, what's up with that?
If, as I'd suspect, that single line below won't be enough code to couple with the info to get to the bottom of it, here's a Dropbox link to the code (since it uses a bunch of files) so you can test it yourself.
It kinda won't work if you try to run it as is tho because it messes up when trying to load all the songs (in the last line of setup), yeah I kinda need some help with that too... works fine if you only load the first one tho!
https://www.dropbox.com/sh/di7mwit0w2l4513/AABipGDAdoKx277f8Hg_ZfhDa?dl=0
(Please, don't expect clear, extensively commented coding. I started working on this way before I learnt that was a thing. Deeply sorry. Of course, you can ask away about anything baffling you)
What did I try, er, writing it well???
I used .play(), .stop(), the volume ones, and they all, as per stated, work fine.
import processing.sound.*;
SoundFile[] songs= new SoundFile[1];
void setup(){
songs[0]=new SoundFile(this,"Small Bump.mp3");
songs[0].play();
}
void draw(){
}
void keyPressed(){
if (songs[0].isPlaying()==1)songs[0].pause();
}
When I copy your code into my Processing editor, I get a couple errors:
songs[0]="Small Bump.mp3";
The sounds array holds instances of SoundFile, but you're trying to store a String value here. Maybe you're looking for the SoundFile constructor?
if (songs[0].isPlaying()==1)
The isPlaying() function returns a boolean value, but you're comparing it to an int value.
songs[i].pause();
You haven't declared this i variable anywhere. Probably meant for this to be a 0.
If I fix all of these errors, then your code compiles fine.
You might want to take a look at the reference for the Sound library here.
The Sound library I had installed was 1.3.2, or something of the likes.
All the references I'd read were for 2.0+.
Having updated that through the "add library" menu, all was solved.
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.
When converting a thrift object for nodejs:
thrift -r --gen js:node state_service.thrift
The following error is thrown:
[ERROR: /state_service.thrift:33] (last token was 'not') Cannot use
reserved language keyword: "not"
The lines in the code around 33 are:
typedef bool Not
struct Exp {
1: string left
2: Not not
3: BinaryOp op
4: AnyValue right
}
I am using the most recent Thrift version 0.9.2
Try to change the not to something else, i think the problem is that 'not' may have another meaning in the language that you choose to generate.
2: Not not
The solution is to not use the reserved language keyword, as advised by the Thrift compiler. These keywords are reserved for a reason. Thrift is a cross-language tool, and not is indeed a keyword in some of them.
I don't want to change the processing code only because of a faulty js converter.
I beg to differ. Faulty is something that does not work, altough it should. Thrift clearly tells you that what you are about to try is illegal (as of today) and what the problem is.
To put it another way: With Linux, you can put uppercase and lowercase letters in a file name (actually you can put a whole bunch of strange things in, but I'll make it easy). So creating a FILE and a file in the same folder will work perfectly. If you now take your program and run it on Windows, relying on that behaviour, you will sooner or later run into trouble and may start to complain you "dont want to change your processing code only because of that faulty OS".
Note that complaining will not help you out of the pothole, altough the endorphines emitted during that process will make sure you have a fun time. The solution is of course to wait until Microsoft fixed their faulty OS, because you make the rules. Correct?
Of course not. So if you feel the implementation is wrong - fine! This is Open Source, and nobody claimed perfection. You are free to provide a patch, and we will happily review it. But please make sure you tested it with all 20+ languages currently supported by Thrift.