Error handling about sverchok HOT 29 OPEN

from sverchok.

The formatting might need some work and I consider writing to a text file and std err as well

from sverchok.

from sverchok.

Absolutely, even worse are nodes that hides the error so there is nothing going red at all.

from sverchok.

The options seem to come down to:

• External log file, slightly better than console, open relevant part in blender text editor on error
• Pipe directly into blender text buffer
• Draw some text in the node editor

They all have their drawbacks and upside, they are not exclusive. A sensible first step would be to start using the logger module.

from sverchok.

I think the most common errors are somehow related to "invalid input": wrong type of data in connected sockets, or unconnected sockets that must be connected for node to function, or invalid amount or "shape" of data. These types of errors i think could be indicated on the node itself. For example mark socket red if it is required to connect it.

from sverchok.

Also now I have prepared for higher amount of pre testing, also with the Required[0] default for node function.
Some nodes might have more advanced needs of socket than on off so raising and error could also be allowed.

[0] Nothing is done with this info yet...

from sverchok.

Yes, that as well, like they should turn yellow if they are missing data today, but today many nodes check themselves and quit quietly...

Agreed on red socket, and as well marking the node/s yellow to show which ones to inspect.

from sverchok.

time to employ the logging module.

from sverchok.

Can we use stethoscope-like drawing to display errors?

from sverchok.

Potentially yes.

from sverchok.

@portnov
Something like this I guess you mean

from sverchok.

Some settings for this could be in the debug panel.

from sverchok.

Did some tweaking but will let further developments be based on further feedback

• print to stdout, should be stderr
• dumps error message to text file NodeTree_Error in blender text editor
• draws it using blf

from sverchok.

We could also show documentation with the same infrastructure.

from sverchok.

full stacktraces in node editor are not very useful imho. Can we draw just short error message there, and print full stack to text buffer?

from sverchok.

A limit it to the last two lines in editor right now which gives file and error. Full trace in console and text editor.
Try and test

from sverchok.

i'm really really liking this.

from sverchok.

now.. if f8 worked ... holy smokes.

from sverchok.

Yeah, it is getting embarrassing. Trying to sort it out now.

from sverchok.

Okay so now I am starting to get a bit worried...
What happens is that the types in

If a module imports objects from another module using from ... import ..., calling reload() for the other module does not redefine the objects imported from it — one way around this is to re-execute the from
statement, another is to use import and qualified names (module.name) instead.

from sverchok.

So it works now, somewhat.
Doesn't result in a lot red nodes at least.

from sverchok.

Nodes can be edited.

Caveats seem to be

• no editing of the base classes, for that a restart is needed.

from sverchok.

i don't get why everything down from svrx can't simply be nixed.

from sverchok.

A brief illustration of the problem.

>>> import importlib
>>> import svrx
>>> x=svrx.typing.Vertices()
>>> t=svrx.typing.Vertices
>>> isinstance(x, t)
True
>>> importlib.reload(svrx.typing)
<module 'svrx.typing' from 'c:\\Program Files\\Blender Foundation\\Blender\\2.78\\scripts\\addons\\svrx\\typing.py'>
>>> isinstance(x, t)
True
>>> t=svrx.typing.Vertices
>>> isinstance(x, t)
False
>>> type(x)
<class 'svrx.typing.Vertices'>
>>> t
<class 'svrx.typing.Vertices'>

What fails is the issubclass/isinstance checks in the parsing of the node types. There where 2-3 other problems of the same kind but they where easily resolvable.

from sverchok.

@zeffii
I am thinking about nice ways to resolve this, but F8/reload is a bit of a hack in python.

from sverchok.

it's weird isn't it. that's the thing that messes with most newcomers heads. as soon as a program starts to get complex... the imports tend to become tricky to deal with (until heavy persistence makes them understood).

from sverchok.

it's almost like quantum physics. " if you think you understand quantum physics, you don't understand quantum physics" . almost.

from sverchok.

I am down to three modules that can't be reloaded.

from sverchok.