New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better error messages in ipengine/ipcontroller #2473
Comments
I found a way:
Result in this:
Can the engine or the controller please print that as well? At least everything which has somethin to do with "ImportError"? |
My code is separated so that I have a "setup" code in my main.py and some functions in another file "functions.py". Main calls a function from "functions.py" which calls main.py:
functions.py
What I don't understand is why it works on one computer and not on the other (both run the same ipython version from today; one 64bit, one 32bit Win7). I tried reverting 46ee6cb on the 32bit side, but that didn't help:
|
My current workaround (and example code...):
|
That's not gibberish, that's ANSI color escapes. To disable the colors, do:
or set |
@minrk It would be nice if that setting could be applied if the underlying system can not read it (i.e. on windows). I'm not sure how to do this: is this acceptable:
Unfortunately the ZMQInteractiveShell.colors is also not in the generated default config :-( |
Not really doable, since the notebook and qtconsole can both draw the colors just fine, and your engines could be on *ix, while your client is on Windows, etc. or vice versa, where that logic would be wrong. The problem is, as I have argued frequently, that colors are hardcoded at the completely wrong time (when the traceback is generated, rather than when/where it is to be drawn). This prevents us from making sensible decisions like you suggest.
That's really a minor documentation issue for generating the default config (which is nothing but a big comment block). It doesn't mean it can't be used. I will make sure to add the ZMQInteractiveShell to the ipengineapp list. |
from my standpoint (and with the ideas in #2489), what is missing here is instead of simple returning the exception to the client, it would be nice if the engine could print the exception to the log: (Pseudocode...)
|
can you test #2818, and see if it is satisfactory? |
so it will appear in default ipengine_config.py, `--help-all`, etc. as [mentioned](#2473 (comment)) in #2473
log user tracebacks in the kernel (INFO-level) Should make debugging errors a little less painful closes ipython#2473
I currently try to debug why my ipengines don't work on one maschine (on another they run fine):
On the ipengine side I get this in the logs (--log-level=DEBUG, This is from a debug run with both engine and controller on the 32bit maschine):
On the controller side I see the engine registered successfully and then sending lots of tasks (
arrived on x
) but no "finished" message. The controller afterwards sends the same tasks out to other engines. There is alsmost no CPU on the engine side.The engines work on a 64bit system, the non-working engines are on 32-bit Win7. Runing the same code "unclustered" works on both the 32bit and 64bit platform.
Running the whole cluster on the 32 bit win7 is resulting in the same problem (see log above, I get the same log when running against the normal controller).
Is there any way to get a better debug message?
The text was updated successfully, but these errors were encountered: