WISH: Disable branches of code

Hi!

Referring to this other thread, which is relevant:
https://discourse.mcneel.com/t/how-to-manage-a-big-definition-any-tips

I still often find myself in a situation where my code is expected to “split” in two or more ways.

No. Or at least not for me, because I need to read and edit my code often … clusters are too cumbersome to have to deal with.

My solution of disabling every component in a group is not reliable enough, it triggers too many “expiration waves” downhill and many similar problems.

@DavidRutten
A “null” object or a parameter having “no sources” would not stop big parts of code from being executed.
Most trivial example:


and similar things happens with all kind of geometry intersections or point/vector/plane handling.
For example: counting the intersections of a line/ray with a mesh, the code is expected to throw an error if no intersection is found (list length == 0). Problem: if the mesh doesn’t exist, that list IS empty, but for a completely different reason.

More than that orange colored wire, if we could have a new type of “state”, maybe colored red, for example, that literally kills the component is is connected to, similar to “disable”, but more dynamic.

Current situation: (again trivial example, real scenarios are much more complex)


All 3 circles exist, every component actually expired, calculated, used CPU time

Wish: (or something similar)


a “killer” status that pseudo-expire the components, but actually just jumpt from the input to the outputs parameters and go on to the recipients components and do the same, killing everything.
No useless components are expired or calculated, not CPU time wasted.
Only one circle exist.
(then, of course, a couple of component able to read/detect this status might be needed)
I am not saying this is a good solution, just an idea…

Sorry for the text wall. I hope I’ve described the problem decently enough.

The problem is there, I have not find a solution if not “hard coding” every parameter with stream gates… doubling the components and wires in the canvas.

I also don’t like clusters for the same reasons…

Until some time ago, I used metahopper to disable the content of a group. Andrew Heuman made a button especially for this on my request.

I got rid of nearly all plugins and started using Stream Gates, dealing with the same null problems like you…

This issue with the annotation dot just got solved…

As you mention above, the multiplication component is the problem

Yeah, but as I also mentioned, real scenario have the same problem even without the multiplication or addition component…



See from orange wire to grey wire…
Both cases here go from “nothing” or “lack of data” to “something”, where list length != 0.
The “orange wire” with no content at all can still propagate into some recipient component that will output a “null” or something else. And that again can make complex logic still try to compute uselessly…
The orange wire is not safe if you expect the rest of the code to just stop computing (like after a stream gate).

It’s hard to completely stop a portion of the code.

1 Like

@DavidRutten
In normal typed coding it is quite simple to “stop” a big portion of code, with a simple “if”.
In grasshopper (and other VPLs?) often big chunks of code are connected to “public values”… so “stopping” only some component at the start of the chunk will not be enough, one should use a stream gate/filter to stop any wire coming from the public values… a mess.

More cases in detail


empty or nulls or no value.gh (21.8 KB)

A null is not an “empty list” … and the other option is “No data was collected.”

Maybe if properly using the “Stream Gate” and “Stream Filter” components one can achieve that sort of “killing wave” I mentioned before… but it is quite hard, you have to intercept every wire going to a portion of code… entangling up all the canvas even more.
And those still propagate an “expiration wave” to all recipient components…

Also an “empty list” give the same color to the wire as the “no data” case: orange.
You can’t distinguish those quickly! (is this possible by changing internal palette colors?)


@Alain @eirannejad @scottd
The last problem, which occurs quite often for me: c# scripts will output a “null” even if don’t output anything at all. (se botton in the picture)
A null is actually “something”, creating a null without reason seems wrong to me…
It isn’t possible to output a “No data” stream from a c#. Would be very handy!
(If I willingly avoid outputting a value to my c# parameters… it should be a “no data” stream)
Even a c# script with a global error will return nulls. Wrong again imho.
And worst case:


The pseudo “killer wave”, “no data” stream is transformed in actually something by the c# script: a null. Here I should put a stream gate/filter before and after the c# script. A mess.

Sorry for the text wall.

2 Likes

Note that the “killing” status/wave I mentioned in the first post, almost already exist, it is that “No data” stream.
For example “List Length” will not compute if provided “No data”.
But some exceptions exist, like addition/multiplication…

Generally Grasshopper should respect better, be more coherent with the difference between:
null <> Empty <> “No data”

There should be a different wire color to distinguish Empty and “No data”.

Powering up “No data” stream or creating a new “killer” status imo would be handy… but for sure I am not able to foresee all possible scenarios.

I know I’m asking something complex.