I'm attempting to use PyVisa inside NodeJS using the Python-Shell module. And I have the python code working, talking to the HPIB equipment. Only, I'm getting the warning-
c:\python34\lib\site-packages\pyvisa\ctwrapper\functions.py:1222: VisaIOWarning:
VI_WARN_CONFIG_NLOADED (1073676407): The specified configuration either does not
exist or could not be loaded. VISA-specified defaults will be used.
ret = library.viOpenDefaultRM(byref(session))
Its only a warning. But because I want to use stdin/stdout to push data into, and receive data from the python code, this warning is causing the wrapper to stop, causing the wrapper to callback with an error.
At least I think that is what's happening.
Any ideas?
Related
There is no code to show as this is a conceptual question. So here is the concise concept breakdown:
Local server (my code) -calls-> acquire_remote_data function (my code) -calls-> data module (not my code) -data module uses-> requests (obviously not my code lol) which requests then throws the above titled exception if the server loses its internet connection temporarily.
I of course, first thing, used the "try/except" method in Python in the acquire_remote_data function to call the data module to quickly realize that it can't capture an exception so far down the path in modules I have no control over.
An option is to contact the author of the data module but who knows when, if ever, they will modify their code to capture the exception if they can.
Is there a workaround technique that can be used to keep this from crashing the server?
*** I figured it out. Using the try/except method was the correct first choice. However, I needed to use the except Exception catch all. I didn't really think of that the first time around because of my darn linter squawking about too general of an exception catch in the past. What I learned was how to shut my linter up about certain issues.
I have a python server running (cherrypy webserver). When a URL /a is hit, it uses ctypes to call a C library function. The library function is causing a seg-fault which results in the python server crashing and generating a 250MB crash dump.
If I use gdb: gdb python python-dump.core then it only shows that the stacktrace has libc.so calls to abort and exit.
Is there a way to get the name of the python function which was last called? And possibly the python variables' values?
I have tried calling the same function directly from a daemon written in C and gdb is able to give me exact function name which is calling the culprit function and the values passed. Is there a way to have the same level of detail when the crash dump is from a python process?
This is my fabric code:
from fabric import Connection, task
server = Connection(host="usrename#server.com:22", connect_kwargs={"password": "mypassword"})
#task
def dostuff(somethingmustbehere):
server.run("uname -a")
This code works just fine. When I execute fab dostuff it does what I want it to do.
When I remove somethingmustbehere however I get this error message:
raise TypeError("Tasks must have an initial Context argument!")
TypeError: Tasks must have an initial Context argument!
I never defined somethingmustbehere anywhere in my code. I just put it in and the error is gone and everything works. But why? What is this variable? Why do I need it? Why is it so important? And if it is so important why can it just be empty? I am really lost here. Yes it works, but I cannot run code that I don't understand. It drives me insane. :-)
Please be aware that I'm talking about the Python 3(!) version of Fabric!
The Fabric version is 2.4.0
To be able to run a #task you need a context argument. Fabric uses invoke task() which expects to see a context object. Normally we name the variable c or ctx (which I always use to make it more clear). I don't prefer using c because I use it normally for connection
Check this line on github from invoke package repo, you will see that it raises an exception when the context argument is not present, but it doesn't explain why!
To know more about Context object, what it 's and why we need it, you can read the following on the site of pyinvoke:
Aside: what exactly is this ‘context’ arg anyway? A common problem
task runners face is transmission of “global” data - values loaded
from configuration files or other configuration vectors, given via CLI
flags, generated in ‘setup’ tasks, etc.
Some libraries (such as Fabric 1.x) implement this via module-level
attributes, which makes testing difficult and error prone, limits
concurrency, and increases implementation complexity.
Invoke encapsulates state in explicit Context objects, handed to tasks
when they execute . The context is the primary API endpoint, offering
methods which honor the current state (such as Context.run) as well as
access to that state itself.
Check these both links :
Context
what exactly is this ‘context’ arg anyway?
To be honest, I wasted a lot of time figuring out what context is and why my code wouldn't run without it. But at some point I just gave up and started using to make my code run without errors.
I'm using python kubernetes 3.0.0 library and kubernetes 1.6.6 on AWS.
I have pods that can disappear quickly. Sometimes when I try to exec to them I get ApiException Handshake status 500 error status.
This is happening with in cluster configuration as well as kube config.
When pod/container doesn't exist I get 404 error which is reasonable but 500 is Internal Server Error. I don't get any 500 errors in kube-apiserver.log where I do find 404 ones.
What does it mean and can someone point me in the right direction.
I know that this question is a little old, but I thought I would share what I found when trying to use python/kubernetes attach/exec for several debugging cases (since this isn't documented anywhere I can find).
As far as I can tell, it's all about making the keyword arguments match the actual container configuration as opposed to what you want the container to do.
When creating pods using kubectl run, if you don't use -i --tty flags (indicating interactive/TTY allocation), and then attempt to set either the tty or stdin flags to True in your function, then you'll get a mysterious 500 error with no other debug info. If you need to use stdin and tty and you are using a configuration file (as opposed to run), then make sure you set the stdin and tty flags to true in spec.containers.
While running resp.readline_stdout(), if you get a OverflowError: timestamp too large to convert to C _PyTime_t, set the keyword argument timeout=<any integer>. By default, the timeout variable defaults to None, which is an invalid value in that function.
If you run the attach/exec command and get an APIException and a status code of 0, the error Reason: hostname 'X.X.X.X' doesn't match either of..., note that there appears to be an incompatibility with Python 2. Works in Python 3. Should be patched eventually.
I can confirm 404 code is thrown via an ApiException when the pod doesn't exist.
If you are getting a mysterious error saying upgrade request required, note that you need to use the kubernetes.stream.stream function to wrap the call to attach/exec. You can see this issue on GitHub and this example code to help you get past that part.
Here's my example: resp = kubernetes.stream.stream(k8s.connect_get_namespaced_pod_attach, name='alpine-python-2', namespace="default", stderr=True, stdin=True, stdout=True, tty=True, _preload_content=False)
Note that the _preload_content=False is essential in the attach command or else the call will block indefinitely.
I know that was probably more information than you wanted, but hopefully at least some of it will help you.
For me, The reason for 500 was basically pod unable to pull the image from GCR
For me the reason was,
I had two pods, with same label attached, 1 pod was in Evicted state and other was running , i deleted that pod, which was Evicted and issue was fixed
I'm using Pywin32 to communicate with Bloomberg through its COM-library. This works rather good! However, I have stumbeled upona a problem which I consider pretty complex. If I set the property QueueEvents of the Com object to True I the program fails. In the documentation they have a section regarding this,
If your QueueEvents property is set to
True and you are performing low-level
instantiation of the data control
using C++, then in your data event
handler (invoke) you will be required
to initialize pvarResult by calling
the VariantInit() function. This will
prevent your application from
receiving duplicate ticks.
session = win32com.client.DispatchWithEvents(comobj, EventHandler)
session.QueueEvents = True <-- this trigger some strange "bugs" in execution
if "pvarResult" is not initialized
I think I understand the theoretical aspects here, you need to initialize a datastructure before the comobject can write to it. However, how do you do this from Pywin32? That I have no clue about, and would appreciate any ideas or pointers(!) to how this can be done.
None of the tips below helped. My program doesn't throw an exception, it just returns the same message from the COM object again and again and again...
From the documentation:
If your QueueEvents property is set to
True and you are performing low-level
instantiation of the data control
using C++, then in your data event
handler (invoke) you will be required
to initialize pvarResult by calling
the VariantInit() function. This will
prevent your application from
receiving duplicate ticks. If this
variable is not set then the data
control assumes that you have not
received data yet, and it will then
attempt to resend it. In major
containers, such as MFC and Visual
Basic, this flag will automatically be
initialized by the container. Keep in
mind that this only pertains to
applications, which set the
QueueEvents property to True.
I'm not sure if this will help for your issue, but to have working COM events in Python you shouldn't forget about:
setting COM apartment to free
threaded at the beginning of script
file. This could be done using
following lines
import sys
sys.coinit_flags = 0
generating wrapper for com library before calling first DispatchWithEvents
from win32com.client.makepy import GenerateFromTypeLibSpec
GenerateFromTypeLibSpec("ComLibName 1.0 Type Library")
If you could post how the program fails (COM object fails or maybe python trows some exceptions) maybe I could advice more.