.rhp debug technique?

Hi,guys.I use vb.net to develop rhp plugs.But,the debug is boring me so much! When I test once,I must restart the rhino!Anyone who has some easy or good ways to debug the plug? Thank you!

1 Like

There is no other way as far as I know.

Unfortunately there is no way to unload, recompile, and reload your plugin into Rhino. It seems like it should be simple to do, but under the hood it is quite complex - especially when your plugin references other assemblies and modules that you write and expect to reload - something we have to assume every plugin does. Failing to reload everything just perfectly would cause bizarre non-repeatable crashes during your debugging session.

That’s the long way of saying… You have to restart Rhino each time.

PITA! PITA! PITA! In case you didn’t get that: PITA!

Couldn’t you come up with something where the debug instance of Rhino can be kept around and then just “re-initialized” with the stuff that would put it back in it’s required plugin-loading state? Just something to drastically reduce the effective reload time. Please? Please. Please!

I suppose this might also require some Visual Studio integration.

But gee-whiz, guys, there seems to be so much plugin development going on now that a little (OK, maybe a little more than “little”) effort on your part could collectively save kilo-hours, if not mega-hours, for developers around the globe.

Not sure if it is feasible in your case, but if you have isolated functions/functionality that you want to test quickly, maybe you can use Grasshopper VB component?

Sorry but there is little we can do here. I would guess that someday Visual Studio will support ‘Edit and Continue’ on 64 bit/mixed mode processes, but that is currently not the case.

The best we can do is focus on minimizing start-up time for Rhino.

Probably. My approach thus far, however, has been to develop functions and classes outside Rhino and save the Rhino-integrated parts for last. By then there’s not too much choice. I’ll need to think about whether your suggestion would be a time-saver.

Is this what you do? How does it work out?

Would it make any sense to have a special stripped-down version of Rhino that has only enough to test a plugin and would be small enough and load-speed optimized for really fast loading? Use a special command-line option to start it, kind of like the other special startups of Rhino? Perhaps it could strip out a lot of functionality that would not be essential for plug-in-centric debugging. When the developer was past that stage and ready to move on to more user and integration orientated testing he could switch to the full-function Rhino.

I’d still rather just focus on making Rhino just load fast for everyone. Having Rhino run in a stripped down mode is going to have you debug something that doesn’t run the same as anyone else’s version of Rhino.

How long are we talking here for restart of Rhino? I do this all day long, and it maybe takes about 5 seconds to get Rhino up and running.

I WAS disappointed!

Looks like Microsoft is focusing on the edit and continue support, so we may have a chance to get this to work in Rhino 6

that’s why python is so usefull as grasshopper to try fast wath you want to do! the real problem is that we are not so able with c# ahahahah!!!

Sounds like really important news. Hope you stay on top of it and get it into 6 if at all possible.

On the question of how long it takes me to restart:

On my Macbook Pro Retina (2012) it takes about what you say: 5-6 seconds. This is with Win8 under Parallels.

On my desktop it takes closer to 30-35 seconds. My desktop does NOT have dual 3.6 GHz Xeon 16 core processors.
It’s (if I remember correctly) a dual core 2.8 GHz from about 6 years ago. This is with up-to-date Win7.
I may not be the only person left trying to write and debug Rhino plugins on such a machine.

hmm… 13 seconds on my win7 laptop. Always feels like a lot longer :blush:

If you start Rhino with the /stopwatch flag, you will get a detailed list of how long different operations at startup are taking. There isn’t anything I can do to really improve these times for V5, but I’m hoping to do something about this in V6.

Thanks, that was interesting.

Looks like Maxwell and Brazil take a bit of time:
(11.5720) - Since Last Record = 2.4210 (%18.37) - Maxwell for Rhino

(12.8220) - Since Last Record = 1.2500 (%9.48) - Brazil for Rhino

I’m sure the stopwatch is correct but it almost looks like things happen before it gets started:


Loading Maxwell for Rhino, version, 2013-04-21 20:14:10
Loading Brazil 2.0 for Rhino 5.0 version May 13 2013 10:04:20
Brazil for Rhino Beta will expire on 31 August 2013
(0.0000) - Since Last Record = 0.0000 (%0.00) - Create Stopwatch

(0.0160) - Since Last Record = 0.0160 (%0.12) - before CRhWGLExtensions::InitWGLExtensions()


though as far as I can tell, these processes also get listed further along the line (as show by the results at the top of this message).

The stopwatch gathers timing information during start-up and then displays it after all of the information has been gathered which is why you see output in the order that you are seeing things.

Oh, oh. Duh! Of course a developer would not want to load a lot of plugins that can’t be scripted anyway while he’s debugging a plugin.

What was the name and flag for the Rhino mode that doesn’t load plugins? Of course, if we start him that way for debugging it (I assume) won’t load the test plugin either.

Now, a user/developer would like to have his modeling Rhino set up with all the stuff, but this conversation makes it obvious that perhaps there is a route to allow a startup of a bare-bones Rhino for development that will only load the test plugin. Maybe this wouldn’t be too hard to set up for R5?

Or am I barking up the wrong tree?

You could go to the plug-in manager and just disable the plug-ins that take a while to load at start-up

Understood. But then when I went back to modeling and wanted to use my modeling configuration, I’d need to go back and manually turn the ones I want back on, wouldn’t I? And back and forth? And wouldn’t I need to go in and reset them the first time I went to debug and waited (forever) for Rhino to load because I forgot to reset the plugins off the last time I was modeling? Etc., etc.

Is it possible to have different sets of Rhino configuration info that can control the loading of Rhino by a single user? I know that different users can each have their own configuration, but my understanding is that this is solely controlled by the logged-in userID and the fact that his app data is in a different (user) directory. Would there be a way for a given user to have selectable load configurations controlled by a command line option and filename? Or something like that?

I’m not saying you have your priorities messed up wanting to make Rhino load faster, but maybe something along these lines could be implemented in a V5 service release while we’re waiting for the smokin’ hot loading and edit & continue V6?

Or can Rhino already do this and I just haven’t read the help deeply enough?