Disabled component expires during solution

Now that I found which component is “expiring during a solution” (whatever that means), I find that it is still doing it’s evil deeds…

This is the Terminator of components…

EDIT : I think I understand what is happening here
This error message appears when I delete some blocks instances in my model, but this component is fed the IDs of all my blocks.
So suddenly, some of these IDs are left dangling.
This suggests that disabled components actually run, but don’t yield an output.

This is disturbing, because I expected these components to be completely inactive.
It means that you can’t really debug a definition by disabling components to pinpoint a culprit.
Maybe @DavidRutten could give more details about this ?

1 Like

@osuire that is not a standard component. As such, it can pretty much do whatever it wants. Also disregard Grasshopper solving rules. Which assembly does it come from?

Hi Giulio, this is an Elefront component.
It allows to change the proprerties of a Rhino object :
-Key
-Value
-Rhino name
-Layer
-Color
-Material

It fills a huge pothole in the standard array of GH components, in my opinion, much like a “Bake” component, and Block-related components we’ve been begging for during the past decade.
Of course, I’d much prefer a standard component strictly abiding by “Grasshopper solving rules”, but a man’s gotta eat.

3 Likes

@osuire The first thing you’d have to do is contact the developer of the Elefront add-on and let them know about this problem. I’m glad you find it useful and there should be ways for them to prevent the error.

:slight_smile:

The error is most likely due to Grasshopper recognizing that the component has code inside, that requests a new computation of the solution while a solution is being solved. This is pretty dramatic. If left alone, this problem would escalate immediately, and probably result in a stack overflow. Even if it doesn’t, there would be no real bound about what is solved by the previous iteration and what is being requested to be solved in the new one. Grasshopper is “gentle” and shows the error, and escapes from the re-entrant code thus preventing a crash. That’s what this means, I think; without the exact code it’s still speculation, though.

I hope this is helpful in clarifying.

For the developer of this type of add-ins: a new solution cannot be requested while an old one is being computed. If you need to contact in private about the problem, please feel free.

Thanks,

Giulio


Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

@piac if that is indeed the bug, would Grasshopper not throw this error every time that the component is added to the canvas and/or activated? I’ve never come across this error throughout our use of the component, and I think @osuire is saying it’s happening while the component is disabled.

A quick survey through the code, and I don’t see anything explicitly calling for a new solution. My first thought is that it’s related to what @osuire is saying about trying to access a guid for which there is no longer an object in the document.

In short, the component access the Rhino object by guid, reads a bunch of attributes, modifies whichever attributes are input to the component, and then executes CommitChanges to the Rhino Object.

The component does check to make sure that the geometry exists, and will send a Runtime Message if it’s not able to grab the actual object. The part I’m a bit murky about is how Grasshopper treats this when the component is disabled. I am also surprised GH would go ahead and execute the code (if that’s what’s happening), and perhaps being disabled means it can’t display the Runtime Message? Kind of stabbing in the dark there.

In summary though - there is nothing explicitly asking for a new solution. Perhaps there is a function that inadvertently calls for a new solution? Either CommitChanges(), or displaying a RuntimeMessage? Would that be enough for GH to intervene and throw the error?

This is probably exactly what’s happening : I didn’t mention it, but after displaying three times the Breakpoint (incidentally, I KNOW there were 3 missing GUIDs because I deleted three blocks), GH goes into Tasmanian devil state , the fans start screaming, and the memory usage goes through the roof. Only solution : shoot it in the head with the task manager.

2 Likes

semi-serious question: is there a way to automate the launch of taskmgr every time Grasshopper is started?

1 Like

The component can listen to events even if it is “disabled”. I have no idea about the source code and only that can tell. I also don’t know who developed this code.

Are you the developer? Do you want to point me to the source, so I can offer to give a second glance? What we do at McNeel, is ask the user, in this case @osuire, for a repeatable case. This usually helps pinpoint the problem and helps in finding a solution. Please, @osuire, could you attach a file that shows this problem?

Maybe. But the error is not about that. It just states that the component expired (= is no longer being computed, at code request) during a solution (= while Grasshopper was trying to reach a conclusion about its connectivity and contents).

Yes, there could be something that creates this infinite loop. I don’t know. Remember that when you use third-party add-ins, you take the awesome bounties in those, but also the additional risk of new bugs also from those add-ins.

Are you sure you really want to push that button ?
Rhino has got apalling Blocks and Attributes management tools, Grasshopper has none.
I love Rhino and I NEED blocks and properties management, so what am I to do ?

@osuire I kindly asked above for a repeatable case. Can you provide it?
I also modified the title, and now will ask you to please keep on the subject.

Yes, but that will imply that you install a bunch of those risky plugins :wink:

@osuire I created the first add-in for Grasshopper that ever appeared. I am aware of the risks. We have at times discussed about first loading add-ins in the Windows Sandbox.

1 Like

FWIW, perhaps @AlanTai and/or @ramon can chime in here. Also, the Support eMail address that can be found on F4R is elefront@frontinc.com.
Apart from that, I’m counting on native support for blocks in Grasshopper 2…
-wim

Not originally, as that was indeed @AlanTai and @ramon, but I’m one of the people currently looking after it. I’ll send you some info separately, see if there’s an obvious issue.

1 Like

I peed my pants ! :rofl:

1 Like